EP3844905A1 - Mobilité préservant la confidentialité, en tant que service pris en charge par une chaîne de blocs - Google Patents

Mobilité préservant la confidentialité, en tant que service pris en charge par une chaîne de blocs

Info

Publication number
EP3844905A1
EP3844905A1 EP19786835.9A EP19786835A EP3844905A1 EP 3844905 A1 EP3844905 A1 EP 3844905A1 EP 19786835 A EP19786835 A EP 19786835A EP 3844905 A1 EP3844905 A1 EP 3844905A1
Authority
EP
European Patent Office
Prior art keywords
data
user data
communication network
distributed ledger
sensitive
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19786835.9A
Other languages
German (de)
English (en)
Inventor
Hideji Wakabayashi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Group Corp
Sony Europe BV
Original Assignee
Sony Europe BV United Kingdom Branch
Sony Corp
Sony Europe BV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Europe BV United Kingdom Branch, Sony Corp, Sony Europe BV filed Critical Sony Europe BV United Kingdom Branch
Publication of EP3844905A1 publication Critical patent/EP3844905A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2143—Clearing memory, e.g. to prevent the data from being stolen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the present disclosure generally pertains to a communication network node, a communication net- work and a method for providing a distributed ledger.
  • a ledger over multiple nodes such as entities, e.g. electronic de vices, servers or the like, which record digital transactions.
  • Distributed ledgers can be based on the known blockchain technology, on which, for example, the known cryptocurrency bitcoin is based, but also the well-known Ethereum project, etc.
  • a distributed ledger may also be imple mented on other technologies than the blockchain technology and examples of distributed ledger projects which are not based on blockchain are BigchainDB and IOTA or the like.
  • IOTA is a crypto currency which uses linked lists.
  • Mobility as a service is known, where a user or passenger uses mobility as a ser- vice without owing, for example, a car or the like.
  • Mobility as a service may combine public (e.g. train, bus, etc.) and private (e.g. car sharing, bicycle sharing, etc.) transportation services from associ ated operators or providers.
  • Known MaaS solutions typically involve a central and unified gateway through which a trip or jour ney is planned and booked, wherein a user may pay with a single account.
  • the disclosure provides a communication network node for providing data to a distributed ledger, wherein the node comprises circuitry configured to provide a user data management part for separating sensitive user data and non-sensitive user data, and provide the non-sensitive user data to the distributed ledger.
  • the disclosure provides a communication network comprising multi ple nodes for providing a distributed ledger, wherein at least one node comprises circuitry config- ured to provide a user data management part for separating sensitive user data and non-sensitive user data, and provide the non-sensitive user data to the distributed ledger.
  • the disclosure provides a method for controlling a communication net work comprising multiple nodes for providing a distributed ledger, the comprising providing a user data management part for separating sensitive user data and non-sensitive user data, and providing the non-sensitive user data to the distributed ledger.
  • Fig. 1 schematically illustrates a blockchain
  • Fig. 2 schematically illustrates hashing in a blockchain
  • Fig. 3 is a flowchart illustrating an embodiment of a consensus protocol
  • Fig. 4 illustrates a data flow in a MaaS system
  • Fig. 5 illustrates an embodiment of a blockchain including journey log data
  • Fig. 6 illustrates an embodiment of a communication network for providing a blockchain
  • Fig. 7 illustrates an embodiment of separating sensitive and non-sensitive data
  • Fig. 8 illustrates blocks of a blockchain including journey data
  • Fig. 9 illustrates pseudonymization of passenger data
  • Fig. 10 illustrates anonymization of passenger data
  • Fig. 11 illustrates an embodiment of using different keys of data protection in a blockchain
  • Fig. 12 illustrates separation of non-sensitive data and sensitive data, where the sensitive data is pro tected
  • Fig. 13 illustrates third party encryption of data
  • Fig. 14 illustrates third party access to data, wherein the sensitive data are anonymized
  • Fig. 15 illustrates an application programming interface for third party access for big data analysis
  • Fig. 16 illustrates a first embodiment for erasing data from the blockchain by invalidating a key
  • Fig. 17 illustrates a second embodiment for erasing data from the blockchain, by erasing blocks
  • Fig. 18 illustrates an embodiment of a general-purpose computer on the basis of which a network equipment or a communication device is implemented in some embodiments; and Fig. 19 illustrates an embodiment of an eNodeB and a user equipment communicating with each other.
  • SaaS mobility as a service
  • the present disclosure pertains generally in some embodiments or aspects to the application of blockchains/ distributed ledger for mobility as a service (MaaS) application, in particular MaaS among more than one service provider (multi-modal transports).
  • MoaS mobility as a service
  • multi-modal transports multi-modal transports
  • the present disclosure also generally pertains in some embodiments or aspects to the application of a distributed ledger or blockchain as one example for a distributed ledger, without limiting the pre sent disclosure to blockchains.
  • Distributed ledgers or blockchains are recognized to be suitable for Mobility as a service (MaaS) applications according to some aspects of the present disclosure, since a distributed ledger requires a distributed database for journey history (or journey data) among multi players, i.e. multiple mobility as a service providers.
  • MaaS blockchains may require to handle a large number of passengers, store various types of journey records, large size of block, peak of processing at rush hour and so on.
  • the distributed ledger or blockchain is suitable for MaaS applica- tion, since it provides a distributed database for a journey history among multiple players.
  • the personal data protection may be challenging for blockchains/ distributed ledger, since the personal data may typically be open for all the members of blockchains and the recoded data in the block cannot be deleted/ modified by user.
  • the distributed ledger in terms of accurate recording of the passenger’s journey, can be shared among players (including mobility service provider) and may even be immuta- ble. Such a characteristic is suitable in some embodiments for the record/ evidence of journey like revenue share calculation.
  • a government transport authority may require to keep the rec ord of passenger information, in particular as it is known for air travel.
  • MaaS journey records may be included in sensitive pas sengers’ information, such as where, when, who and what the passenger is doing.
  • anonymization and pseudonymization may be applied.
  • requirements for protecting the personal data exist, such as the general data protection right (GDPR).
  • some embodiments pertain to the issue of how to protect personal data with access control and how to provide a method of anonymization and pseudonymization of passengers’ data.
  • personal information is confined to an inaccessible part of a system, which may not accessible by a third party.
  • confidentiality of user profile/ multi-modal pass information is ensured by a mobility service provider which has the con tract with a user, whereas user specific ID, for example, is anonymized in a distributed ledger or blockchain.
  • a journey log included in a distributed ledger or blockchain may be under access control and the contents of the journey log may be pseudonymized.
  • distributed ledger may be known from Wikipedia, which defines:“distributed ledger (also called a shared ledger, or distributed ledger technology, DLT) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or insti tutions. There is no central administrator or centralized data storage.”
  • distributed ledger is used as a type of data base shared digitally recorded data with multiple nodes of a network. It may be comprised of peer to peer network.
  • the digitally recorded data may include a kind of information to prove its consistency from the previously recorded data on the same database.
  • Distributed ledgers can be public and can be accessible by anyone, but, in principle, they can also be non-public and only users having a permission may have access to them, wherein a group of entities, nodes, persons, operators, providers or the like which have the permission may also referred to as “consortium”, as will also be explained further below. It is also possible to differentiate the access permission to data on a ledger from each layered users.
  • Distributed ledgers can use mechanisms, which are known, for example, from the blockchain tech nology as used for bitcoin. Such mechanisms include a discovery method, a consensus mechanism, a mechanism to keep data consistency and so on.
  • the consensus mechanism ensures that all nodes or more than a certain number of nodes, generally electronic devices, having a copy of the distributed ledger reach consensus on the content of the distributed ledger.
  • consensus mecha nisms including the so-called proof-of-work mechanism, which is some kind of crypto-puzzle and which ensures that, for example, older blocks of a blockchain cannot be changed (easily).
  • proof-of-work is used for the mining process of the bitcoin blockchain.
  • a confirmation process to make a consensus about data re- newal on a blockchain in attending nodes may achieve irreversibility of the sequence of transactions recorded on the blockchain by including previous recorded data in the con firming data.
  • Such mining process implements a distributed timestamp server for a new block of transactions.
  • the mining process is based on the SHA- 256 hash function. Nodes of the blockchain that participate in the mining process search for a hash output with predefined properties while the input of the hash function depends on the current blocks of the blockchain and the new block of transactions to be added to the blockchain.
  • Proof-of-work computations based on hash functions may not be useful in themselves except that they are required to implement the irreversibility of the distributed ledger.
  • a blockchain for storing a variety of data. For instance, im- ages, videos, measurements, and text files can be recorded on the blockchain in the form of a trans action.
  • Mobility as a service is also known from Wikipedia, which defines:“Mobility-as- a-Service (MaaS) describes a shift away from personally-owned modes of transportation and towards mobility solutions that are consumed as a service. This is enabled by combining transportation ser- vices from public and private transportation providers through a unified gateway that creates and manages the trip, which users can pay for with a single account. Users can pay per trip or a monthly fee for a limited distance.
  • the key concept behind MaaS is to offer travelers mobility solutions based on their travel needs.”
  • A“Public blockchain/ distributed ledger” means in some embodiments, that anyone can share the distributed database (ledger) and join to execute the consensus protocol, as also indicated above.
  • a“Permissioned blockchain/ distributed ledger” means that only permitted mem bers can share the distributed database (ledger) and join to the consensus protocol. Permitted mem bers which have the permission to access the blockchain are called“consortium”, as indicated above.
  • permissioned/ consortium type blockchains are suitable for MaaS ap plication, since they are not public and, thus no one can access it.
  • MEC Multi-access Edge Computing
  • formerly Mobile Edge Computing is a network architecture concept that enables cloud computing capabilities and an IT service environment at the edge of the cellular net- work[l] [2] and, more in general at the edge of any network.
  • the basic idea behind MEC is that by running applications and performing related processing tasks closer to the cellular customer, net work congestion is reduced and applications perform better.”
  • Northbound API is understood in a network virtualization context in the sense that a telecom operator can configure the network function with a software based interface (API) and that the network operator may configure the virtual infrastructure (e.g. virtual machine) and requested network functions/ application functions.
  • API software based interface
  • the term“Instance” is understood as a software process running on a cloud. It may move some where in the distributed cloud.
  • A“Public cloud” may be defined as (https:/ / azure.microsoft.com/ en-gb/ overview/what-are-pri- vate-public-hybrid-clouds/):“Public clouds are the most common way of deploying cloud compu ting.
  • the cloud resources like servers and storage
  • multimodal transport pass may be a pass which is valid for multi mobility services with specific conditions, such as valid period or available transport, unacceptable services, etc. For in stance, a one-day ticket, one -week ticket, monthly MaaS service subscription, seasonal ticket, etc.
  • mobility service provider may be a catch-all name of any type of service provider MaaS. In some embodiments, it is typically a transport organization, such as railway companies, bus/ coach, tram and taxi, car sharing, ride sharing, bike sharing and so on. Some of the mobility service provid ers may not provide the actual transport means, but may provide only a booking/ arrangement, com parable to a travel agency or online booking site or the like.
  • the term“Pass” may be a transit pass or travel card (UK) (see also https:/ / en.wikipe- dia.org/wiki/Transit_pass).
  • a multi-modal pass shall also fall under the term“pass”, which means that the pass may be valid among more than one transport operator (or mobility service provide) and, thus, it may cover not only public transport, but also cover other types of mobility, such as ride share, bike share, etc.
  • the pass may include the information of ac ceptable transport, valid period, and any other conditions of ticket issue/ transport ride.
  • the MaaS may provide a monthly service subscription with some option of service level in some embodi ments.
  • a passenger or user may pay the service subscription fee or purchase of specific period pass to a pass issuer (which may typically be a mobility service provide which issues the pass).
  • the pass may be issued by transport operators or travel agencies, MaaS service provider, etc. (which may all fall under the term mobility service provider as discussed above).
  • some of the pass issuers may sell a pass, but may not provide the actual transport service or transport means.
  • Ticket may be a ticket for a one-way journey of the specific section like one-way train ticket with (or without) seat reservation.
  • the ticket may be issued under the multi-modal transport pass and its terms and conditions in some embodiments and it may include the information of se lected transport, seat number, price, etc. In some embodiments, even if no seat reservation is re quired or unlimited travel is allowed, the ticket may be issued for revenue sharing among multiple mobility service providers.
  • a passenger (user) may not directly pay for a ticket issuer, but a pass issuer may pay for the ticket issuer instead of the passenger and the ticket may be issued by a transport operator or service provider, i.e. by a mobility service provider.
  • the term“Journey log” may cover a journey log which is a one-way journey record based on the ticket. It may include information about the location of embankment, time/ day of it, the location of alight, time/ day of it, whether the ticket is used or unused, etc., which will also be discussed further below.
  • “anonymization” may be defined in accordance with Wikipedia (see also https:/ / en.wik- ipedia.org/wiki/Data_anonymization):“Data anonymization is a type of information sanitization whose intent is privacy protection. It is the process of either encrypting or removing personally identifiable information from data sets, so that the people whom the data describe remain anony mous.”
  • Pseudonymization is a data management and de-identification procedure by which personally identifiable information fields within a data record are replaced by one or more artificial identifiers, or pseudonyms. A single pseudonym for each re placed field or collection of replaced fields makes the data record less identifiable while remaining suitable for data analysis and data processing.”
  • GDPR General Data Protection Regulation
  • EU General Data Protection Regulation
  • personal data may be understood in some embodiments in the sense (see exemplary https://gdpr-info.eu/ art-4-gdpr/):“(1)‘personal data’ means any information relating to an identi fied 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 identifi cation 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;”
  • The“pseudonymization in GDPR” may be understood accordingly as:“(5)‘pseudonymization’ means the processing of personal data in such a manner that the personal data can no longer be at tributed to a specific data subject without the use of additional information, provided that such addi tional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;”
  • the term“public-key cryptography” is understood as defined also in Wikipe dia (https://en.wikipedia.org/wiki/Public-key_cryptography):“Public-key cryptography, or asym metric cryptography, is any cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner.
  • the term“salt) is understood in accordance with Wikipedia (https:/ / en.wik- ipedia.org/wiki/Salt_ (cryptography)):“In cryptography, a salt is random data that is used as an addi tional input to a one-way function that "hashes" data, a password or passphrase. Salts are closely related to the concept of nonce. The primary function of salts is to defend against dictionary attacks or against its hashed equivalent, a pre-computed rainbow table attack.”
  • some embodiments pertaining to basic techniques are discussed, includ ing sensitive data separation (with off-chain technique) and a naive method of pseudonymization and anonymization (with scrambling and/ or hashing).
  • some embodiments pertain to the access control of data, wherein the access control may include a level of Access control, a block encryption with different access keys, and/ or open data and API.
  • some embodiments pertain to erasing of sensitive data, including, for example, key invalidation and/ or block erase.
  • Hash function participant authentication, a scalability/block structures and performance.
  • Fig. 1 illustrates a general structure of a blockchain 1.
  • the blockchain 1 includes a chain of multiple data blocks 2a, 2b and 2c, wherein the block 2b is a current block (Block #N), the block 2a is a pre vious block (Block # N-l) and the block 2c is a future or successor block (Block # N+l).
  • Each block includes a hash function result of a previous block, a main data structure, an input value for hash function and hash function result of the current block, wherein the hash function result of cur rent block (2b) is always used as input to the next block (2c).
  • each block includes a“Number used once”, which is a one-shot random number for a secure blockchain processing, and which can prevent replay attack. For instance, if an attacker cop-ies the previous transmitted data and reuses the copied data again for spoofing, the receiver is able to detect the spoofing communication because the next data must be used with a different“number used once”. This random number is sometimes referred to as“nonce” in cryptocurrency.
  • the time stamp may be inserted in each of the blocks 2a, 2b and 2c.
  • the blockchain 1 is an example of a distributed ledger, which may be used, for example, for providing MaaS in some embodiments.
  • Fig. 2 illustrates the input and output of a hash function, which is used, for example, for the block- chain 1 of Fig. 1.
  • a hash function is any function that can be used to map input data to output data with a specific algorithm.
  • the size of input data can be large and various, contrarily the output of data could be compact and can have a fixed size.
  • a known (and famous) algorithm which is used for hashing in some blockchain embodiments is the Secure Hash Algorithm (SHA) designed by the United States National Security Agency (e.g. SHA -2, SHA -256).
  • SHA Secure Hash Algorithm
  • the input for the hash function are a previous hash output, the number used once and the main body of data in the current block (e.g. block 2b in Fig. 1).
  • the output of the hash function is a unique value response to the input values. If someone tries to tamper the main body of data, the output of hash function cannot be consistent.
  • Embodiments of a distributed ledger (blockchain) in this disclosure may implement a consensus protocol or algorithm.
  • the Byzantine Fault Tolerance (BFT) is used for the consensus protocol, which is resilient to spoofing of database and fault of hardware.
  • PBFT Practical Byzantine Fault Tolerance
  • a permission blockchain is used and the relatively small number of permis- sioned blockchain nodes are in charge of consensus (validation of block).
  • Fig. 3 exemplary illustrates the process 10 of PBFT.
  • a leader node requests at 11 other nodes to validate the block- chain.
  • each requested node (validate peer) checks the validity of the blockchain with a hash function and indicates its result to other nodes at 13.
  • a node receives the validity results from multiple other peers and checks the consensus of the blockchain, if it receives more valid results than a pre-defined criteria. If there is a consensus, at 15, the node writes/ finalizes the blockchain.
  • the PBFT is with permission blockchains for mobility service blockchains, as discussed herein, providing at least partially the following features:
  • security the PBFT provides in some embodiments a little risk of 51% attack, which is common for cryptocurrency because permission the peer which is in charge of consensus must be trusted.
  • privacy the end user cannot access the whole blockchain because only mo bility service providers handle it at a (peer) node (due to the permission based blockchain and end users may not have the permission to access the blockchain).
  • the pro cessing time for consensus is very short in some embodiments due to a small number of peers hav- ing a high performance.
  • the block size and format of blockchains can be flexible compared to public blockchains in some embodiments.
  • a MaaS system 20 illustrat ing the overall data flow.
  • the end-user has an own terminal 21, e.g. a smart phone (or any other type of electronic (mobile) device).
  • Some users e.g. visitor from oversea
  • proxy function proxy 22
  • Fig. 4 illustrates the data flow diagram of the MaaS system 20, wherein three main sections are pro vided, an end-user section on the left side, a mobility service operator/ provider section in the mid- die and an other entities section on the right side, wherein the end-user section and the other entities section communication with the mobility service provide section in the middle.
  • the mobility service provider has a user management function 23 with a web server or cloud for customer services and a user profile management function 23a and a passenger journey management function 23b. It further has a block- chain management function 24.
  • the blockchain function 24 having the block chain management function 24a communicates with blockchain management functions 25 of other entities section. If a seat reservation/ shared ride booking is provided by a booking center 26, a central booking server/ cloud is provided.
  • the end user communicates with its own terminal, i.e. smart phone 21 in this embodiment, which has exemplary a user interface and sensors, e.g. GNSS, NFC, etc.
  • the end user can perform, for example, the following actions with the terminal or via the proxy 22: Subscription of services/ purchase of one day / one week ticket; booking of train, reservation of car/ ride share; transport embark/ alight permission/ record; post processing after alight (e.g. customer survey, refund or compensation of delay), etc.
  • the user profile management function 23a is configured to store static data, e.g. name, age, contact address, payment method (e.g. credit card), service subscription status, the preference of transport, any other unique ID like TMEI, etc. and communicates with the terminal 21.
  • the passenger journey management function 23b is configured to perform several actions and to communicate with the terminal 21.
  • a multimodal transport pass it man ages, for example, a subscription of MaaS monthly service and a purchase of one-day ticket, one- week ticket, etc.
  • a journey planning or journey planner
  • it provides destination in- put, route selection/ transport options, booking/ travel arrangement and issues the ticket and issues the ticket ID, generates itinerary for the passenger and issues the itinerary ID etc.
  • the passenger journey management function is configured to start the journey and, for each section of the journey (iteration), to check the pass/ ticket hold and record the embank ment, record the alight and add the journey log to the blockchain, and at the end of journey to ter- minate it and to close the itinerary.
  • the blockchain management function 24a communicates with the passenger journey management function 23b and the other block managements 25. It is configured to add, to validate/ execute con sensus protocol and to read the blockchains. Moreover, as can also be taken from Fig. 4, the pass, ticket and journey log information is communicated at least between the passenger journey manage- ment function 23b and the block chain management function 24a and between the block chain man agement function 24a and the other blockchain managements 25.
  • the blockchain 30, as also generally explained under reference of Fig. 1, has several blocks 30a, 30b, 30c, wherein in Fig. 5 a past block 30a (Block #N-1), a current block 30b (Block #N) and a successive sor or next/ future block 30c (Block #N+1) are exemplary illustrated.
  • Each of the blocks 30a, 30b and 30c can include one or more passenger logs in a transaction within a maximum given block size and within an associated data structure.
  • the block 30a on the left hand side (Block #N-1) handles two passenger logs 31a and 31b.
  • the hash output from the N-l block 30a is provided to the next N block 30b (current block).
  • the block 30b (Block #N) handles the next journey logs 32a and 32b of passengers A and B, and, additionally, a journey log 32c of a passenger’s C journey. If, for example, a passenger D issues a new journey log, but if simultaneously the block size limit is exceed, the further journey log will be handled in the next block, i.e.
  • block 30c in the present example which includes a further journey log 33a entry for passenger B, a further journey log entry 3cb of passenger C and a further journey log 33c entry for passenger D, such that the block 30c (Block N+l) handles the next journeys of passenger C and D and the remaining log of passenger D. Then, the hash output (N+l) is provided to the next block (N+2) (not shown in Fig.
  • a journey log in the blockchain 30 may include at least one of the following information: - Issuers: multimodal transport pass issuer, mobility service provider/ transport operator, passenger id (anonymized data).
  • Type of ticket Type of transport (railway, rideshare and so on), Seat reservation (train/ seat number), Price or ticket, Terms and conditions.
  • the blockchain for MaaS is assumed to use permissioned blockchains.
  • permissioned blockchains only permitted operators (forming a consortium) can add/ read block and limited participants are allowed to join the validation of transaction (i.e. consensus with trusted play ers).
  • the mobility service providers are organized in a consortium and only those having the according permission are allowed to access the permissioned distributed ledger or blockchain, while malicious participants or dishonest ones cannot join the con sortium of blockchain.
  • the communication network 40 mitigates the risk of single point of failure (SPOF), which is typically the weak point of systems, e.g. for conventional systems which are heavily relying on the central of server could be SPOF in the system.
  • SPOF single point of failure
  • the communication network 40 has multiple nodes (or entities) 41
  • the mobility service provider nodes 41 may form together a com munication network 40, which provides the permissioned blockchain for MaaS (e.g. blockchain 30 of Fig. 5).
  • a passenger 42 subscribes, for example, the monthly MaaS service provided by mobility service pro vider or buy one-day/ one-week pass for multi-modal transport services by communicating with its terminal (e.g. terminal 21 of Fig. 4) with the associated mobility service provider.
  • the mobility service provider 41 could be a new service provider, such as MaaS operator (e.g. shared ride), bike sharing service provider, travel agency in addition to conventional transport operators such as car railway companies, tram operator, as mentioned.
  • the mobility service providers 41 connect to one another over the communication network, which is a logical connection, wherein a direct connection among operators or mobility service providers is not necessarily required, but it may require low latency and high throughput.
  • the entity or node 41 of a mobility service provider may have various functions, but there are two main functions, as also discussed above for Fig. 4, namely a passenger management function and the blockchain management function.
  • the passenger management function supports booking of seat, booking of shared ride/ taxi/ car rental/ seat reservation of train, monthly subscription or buying one-day ticket and so on.
  • a normal e-commerce site it provides a user interface of website or smart phone back-end processing.
  • the blockchain is hidden for the end-user in the present embodiment, but it is accessed with and by multiple mobility service providers.
  • a consortium (permissioned) blockchain is implemented among nodes 41, which validates the block- chain ledger among the mobility service providers which are members of the consortium.
  • this above example is extended to international MaaS operation or MaaS op eration in different regions.
  • the blockchain is then defined as a multi-tier structure.
  • the first tier blockchain is configured between countries or between regions and the second tier blockchain is configured in the consortium of the region.
  • a representative provider in regional con sortium may join the first tier blockchains and handle the international services.
  • some embodiments pertain to the separation of personal information of a user in ser vice subscription/ user pro files.
  • the full data 50 includes personal (sensitive) in formation (e.g. passenger, name, home address, telephone, number, gender, age, passport number, credit card number, etc.) as well as non-sensitive data, such as journey data or statistics of the jour ney.
  • personal (sensitive) in formation e.g. passenger, name, home address, telephone, number, gender, age, passport number, credit card number, etc.
  • non-sensitive data such as journey data or statistics of the jour ney.
  • Fig. 7 illustrates, that the full data 50 is split into the non-sensitive data 50a and the sensitive data 50b, such that the non-sensitive data 50a and the sensitive data are separated from each other.
  • a passenger may be required to input the personal data like as name, age, home address, telephone number, credit card number, passport number/ travel docu ment, and so on. These are likely to be mixing the sensitive data and non-sensitive (non-identifiable) data. Therefore, in this embodiment, the sensitive information/ data 50b is separated from the full data 50 and the sensitive data is handled with extra care and stored in a safe place.
  • a mobility service provider if a mobility service provider has the credit card information, it must comply in some embodiments with industry security standards such as Payment Card Industry Data Security Stand- ard (PCI Standard). Hence, in such embodiments, the database and network are protected from an external network with a firewall.
  • PCI Standard Payment Card Industry Data Security Stand- ard
  • a database for sensitive information is detached from blockchains nodes and its network (such as nodes 41 in Fig. 6 and the network 40).
  • this separation of sensitive and non-sensitive information is performed with an off-chain technique, as also illustrated in Fig. 8, which shows to blocks 55 and 55 of a blockchain.
  • the relation between passengers’ personal data and blockchains is unbundled.
  • the sensitive data (50b Fig. 7) is not included in the blockchains (which is also referred to as off-chain).
  • the personal data (sensitive data) is stored inside a MaaS provider (e.g. database, storage or the like) and is not added to blockchains.
  • Fig. 8 illustrates an example of a ticket and journey record of a MaaS service.
  • the ticket may be is sued by a ticket or pass issuer (e.g. transport operator) or other MaaS service provider.
  • the passenger name or any personal data is not included, but only a (unique) ticket number is included in the data structure of the blocks 55 and 56 of the block chain, 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 which is associated with a certain passenger and a journey log identifier.
  • the blockchain is open for other members of the consortium, but they can only see the ticket number and not the sensitive data of the passengers (users). There is no clue who is the actual passenger in the blockchain. Only the ticket or pass issuer (or MaaS service provider) can identify the actual passenger name and identity, because he has the sensitive infor- mation stored in its database separated from the blockchain and associated with the ticket number..
  • the reservation system e.g. provided by a mobility service provide, should keep the personal data of the passenger, since, for example, if the name of an air ticket and that on the passport do not match, boarding is typically not allowed.
  • the blockchain members re quest the required information from the MaaS provider who has the personal data of the passenger, e.g. based on the ticket number or any other identified which is associated with the passenger.
  • the off-chain technique cannot be applied, and, thus, in some em- bodiments, personal data of passengers in the blockchain are subject to pseudonymization and/ or anonymization (see next section).
  • the personal data like passenger name is required to be included in the block(s) of a blockchain, the name (or any other personal data) should be protected.
  • the personal data is replaced, and a typical way of pseudonymization is to replace the sensitive part with characters or numbers, or zero padding, or even removing it.
  • a typical way of pseudonymization is to replace the sensitive part with characters or numbers, or zero padding, or even removing it.
  • the personal data is removed in some embodiments.
  • scrambling is implemented, which is also illustrated in Fig. 9, where a method 60 of pseudonymization with scrambling is shown.
  • the input data 61 is split into two parts, namely in an unprotected part 62 including the pass issuer information and a protected part 63 including personal data, namely the passenger ID.
  • the data of protected part 62 are input as a stream to scrambling processing 64 (“+”).
  • scrambling processing 64 the protected data 62 and a scrambling code 65 are applied to each other (math ematically Ex-OR calculation).
  • pseudonymized passenger data 66 are generated, which are combined with the unprotected part 62 as output 67.
  • the pass issuer (who knows the scrambling code, or any other entity which knows the scrambling code) can de-scrambling and unmask the passenger ID.
  • the pass issuer who knows the scrambling code, or any other entity which knows the scrambling code
  • the scrambling code is also configurable and a scrambling code is selected among a large amount of candidate codes, such that this may be similar to an encryption key.
  • the scrambling technology allows a simple hardware/ software algorithm and scrambling is typically reversible (at least as long the scrambling code is available).
  • the original source of data can descramble it, if necessary or needed.
  • reversibility may not be required in some embodiments. For example, if there is a mali cious member among the blockchain members, it is possible to identify the user ID and to get the information, and, thus, in some embodiments non-reversible implementations are needed.
  • scrambling The main purpose of scrambling is data masking, and there is no key, but there is just a code num ber is set (i.e. initial value of shift register). If someone accidently sets the same code, it is easy to de scramble the data. Moreover, scrambling of data may be vulnerable for trying all possible combina tions, i.e. descrambling on the basis of a brute force attack may be possible. But, scrambling typically only involves light processing load and is easy to handle, such that it is also implemented in some embodiments, among trusted members, e.g. in a consortium of trusted members.
  • encryption On the other hand, the main purpose of encryption is to provide data in secret.
  • the algorithm of encryption is commonly open for everybody and it may use, for example, public key for de-encryp tion (if PKI). This is especially useful for public/untrusted groups, as it is the case for the Internet.
  • encryption may involve heavy processing load of de-encryption, complex algorithms and may also not be free available, but may be protected, e.g. subject to intellectual property.
  • GDPR requires an irreversible process for anonymized data. For example, if the data is openly provided to third party, the personal data must be anonymized.
  • FIG. 10 An embodiment of a method 70 for anonymizing data is illustrated in Fig. 10, wherein a hash func- tion 71 is used for anonymization of data.
  • a hash function is any function that can be used to map input data to output data with a specific algorithm.
  • the size of input data can be large and various, contrarily the output of data could be compact and may have a fixed size.
  • the input of the hash function 71 is personal data 72 (or any protection needed data) and a salt 73 of hash (or any initialization random values).
  • the output of the hash function are anonymized personal data 74 which are a unique value response to input values, wherein this hash output 74 is irreversible.
  • the salt 73 is separately stored and protected.
  • the salt key is changed, e.g. every time on application, such that this en hances the anonymization, since in this case, even if the input is the same user ID again, the output is different, since a different salt is used.
  • the anonymization of the data is non-reversible, thereby also providing a intractability.
  • This untraceable characteristic is suitable for perfect anony mization, in some embodiments, wherein it is impossible to access the original data after hash out put.
  • this method 70 is especially useful in some embodiments for permanently removing the per- sonal data, when, for example, the data is provided to third party for statistics/big data analysis.
  • some embodiments pertain to the access control to the distributed ledger or block- chain.
  • the general advantage of distributed ledger is that all the members may access the distributed data base. However, the personal information should be protected and should not share without re- striction in some embodiments, and, thus, in some embodiments, depending on the purpose of data use, the data access is restricted.
  • the access control depending on the purpose of data use, may involve the following and/ or may have the following characteristics (alone or in combination):
  • Such a pro- vider has sensitive information of customer/ passengers on service subscription/ purchase, as also discussed above. This sensitive information including the personal data is to be protected, wherein pseudonymization is required for writing into blocks of a blockchain.
  • the ticket issuer/ transport operator keeps the relevant infor mation in line with transport regulations. Depending on the type of transport (e.g. airways, railways, bus, etc.) and the type of ticket (e.g. registered passenger only), the required information may be dif ferent. The transport operator does not access unnecessary information. In this case, pseudonymiza tion is required for writing into blocks of a blockchain.
  • - Data analyzing by third party The third party must not access the sensitive information. Hence, the third party should not be able to identify the personal information and it should not access pseu- donymization data. Therefore, in this case anonymization is required for before the data access.
  • - Passenger The passenger has the right of own information control and to delete the information, but the passenger is not allowed to access other passenger’s information and the passenger may not directly access the blockchain or distributed ledger.
  • the public safety authority may access the full information of passengers in the event of emergency.
  • the special encryption key is required to access the full information of passengers.
  • a permissioned blockchain is implemented, and in permis- sioned blockchains, e.g. consortium, only a permissioned entity can access the distributed ledger/blockchain.
  • permis- sioned blockchains e.g. consortium
  • the security level in consortium is higher than the public blockchains.
  • the encryption with a separate key is also beneficial for access control.
  • the sensitive data should be encrypted with a first key 81 (master key) which is only known to the MaaS provider having a contract with a user which is associated with the user profile data.
  • a user management function 82 has a user profile management function 82a and a passenger journey management function 82b, such that the user profile data (sensitive data) und the passenger journey data (non-sensitive data) are separated from each other and can also be handled differently and separately.
  • the user management function 82 communicates with a blockchain management function 83, which in turn communicates with one or more blockchains 84.
  • a firewall 85 is provided between the user management function 82 and the blockchain management function 83 for protecting the sensitive data, and the user management function 82 and the blockchain management function 83 may be located on different entities, e.g. different servers or other computing devices.
  • the master key 81 is used for encrypting the sensitive data, such that the sensitive data is protected through the firewall 85 and the encryption.
  • the MaaS provider generates a second key 86 (service provider key).
  • This second key 86 can be shared with other MaaS providers and can use it for blockchains, i.e. for the encryption of data which is stored in blocks in the blockchains 84 by the blockchain management function 83. If the members which have access to the blockchains 84 are highly trusted and the number of mem bers are not so large or members do not frequently change (e.g. in a consortium), the private key en cryption is still preferable.
  • the same key can be used for long period. Or even just scrambling with specific se- quence generator without key is also possible in some embodiments in such cases, which may avoid the key distribution.
  • the other mobility service providers also access the blockchains 84 over a blockchain management function 87 which is separated from blockchain management functions 88 of third parties via a fire wall 89.
  • a third key 90 is provided, which is shared with third parties, such that the third parties may have access to information of the blockchains which is secured with the third key 90.
  • a MaaS operator 95 has a contract with a passenger, as mentioned also above, and, thus, the MaaS operator 95 has also the passenger’s sensitive information and data.
  • a transport provider/ operator #1 issues a ticket 96 based on the MaaS operator contract with the passenger, but the transport operator #1 does not have the passenger information details.
  • the MaaS operator has the details of passenger information, i.e. the sensitive information, and in serts it in the ticket issued by the transport operator #1, wherein it is encrypted with the public key encryption of the specific transport operator, in this case transport operator #1. This information is put into a block including the ticket 96 of a blockchain, as discussed above.
  • the transport provider/ operator #1 can de-encrypt the protected data in the block received from the blockchain with its own private key.
  • the secret private key has not been shared with other transport operators.
  • the data are open data.
  • the third key (see Fig. 11) should be shared with other third parties for data analysis (e.g. for getting statistics, big data analysis or the like).
  • the transport operators have the third party public key 100 for open data.
  • the third party private key 100 is shared with multiple third parties who would like to use it for data analysis.
  • the transport operator #1 inserts the data in a block illustrated as block 101 with encryption of the open data based on the third party key.
  • One or more of the third parties can de-encrypt the open data with the secret third key 100 for open data, but cannot de-encrypt the protected data, which is encrypted, as discussed above, for example, with a private key only known to the mobility service providers.
  • third party key If more than one third party key is used, it is possible in some embodiments to provide multi-level access control (depending on the level of data confidentiality) or access control of specific groups (depending on the belonging group of third party).
  • the protected data (i.e. the sensitive data) in the block can be anonymized.
  • the anonymized data and the open data are combined in the blockchain.
  • the transport operator #1 (ticket issuer) generates anonymized data (e.g. passenger name), with a salt and the hash method as discussed above under reference of Fig. 10, which are input into a block 105 for a blockchain.
  • the block 105 also has open data (e.g. destination) which is encrypted with the third public key.
  • the ticket number and the ticket issuer #1 are stored in the block, as also discussed above.
  • the third public/ secret key is shared with others and can be used for de-encryption o the open data in the block 105, whereas the anonymized data cannot be de-encrypted and can also not identified, as discussed above.
  • API application programming interface
  • Fig. 15 basically corresponds to Fig. 11 and the same reference numbers also denote the same enti- ties and functions.
  • a database 110 for big data is provided which also provides an API which can be accessed by third parties for a big data analysis function 111.
  • the transport statistics/data stored in the database 110 for big data could be useful for public and commercial purposes. For example, governments may use it for city planning and the private com pany may decide the location of a new shop based on it.
  • the big data in this embodiment is com monly accessible and the data is available with the open application interface (API) 110 for wider third parties.
  • API application interface
  • a mobility service provider or trusted data base provider on behalf of a mobility service provider stores the data in the database 110 without sensitive information.
  • the mobility service provide or trusted data base provider provides the API 110, which access the database, for external third par ties.
  • An external third party can access the database 110 without key (optionally with key).
  • the API 110 may include an identity check in order to prevent malicious access.
  • the API may support authentication protocol like OAuth 2.0 (RFC 6749) (https:/ / oauth.net/2/).
  • sensitive data may be erased from the blockchains, and, in the following, em bodiments pertaining to erasing of sensitive data are discussed under reference of Figs. 16 and 17.
  • blockchains are implemented such that data cannot be erased, since blockchains are origi- nally intended for permanent data store.
  • a method 115 for erasing sensitive data from a blockchain is keeps the sensitive or to erased data in the blockchain, but invalidates the key
  • one or more of the members of the consortium of mobility service providers request to delete the personal data in the block (or any sensitive data) to host 116.
  • the host 116 sends/broadcasts at 118 the request for invalidation of the key to the other blockchain members of the consortium.
  • the other blockchain members delete the key and send at 120 the acknowledgement to host 116.
  • the host sends the confirmation of data erase to the requester.
  • the key has timer or validity time/date (or data itself has validity timer), and the key may be automatically deleted after the time/date is expired or a de-encryption algorithm may reject the key after the time/date expired.
  • FIG. 17 Another embodiment, of a method 125 for erasing sensitive data from a blockchain is illustrated in Fig. 17, wherein the blockchain is erased after consensus of consortium members and wherein same reference numbers denote the same entities and functions or method steps.
  • One of the members of the consortium requests to erase the (sensitive) data, wherein another mem ber has the blockchain and the associated key for it.
  • one (or more) member requests to delete the personal data in the block (or any sensitive data) to the host 116.
  • the host 116 sends/broadcasts the request of block erase to the other blockchain members, wherein the request may be to erase a specific part of a block, multiple blocks or all parts of the blockchain (i.e. the whole blockchain).
  • the other blockchain members check whether it is acceptable or not. If it is acceptable, they send an agree command at 126 to host 116. For example, if a revenue share calculation has not been finished yet, the other members may send a reject or wait command.
  • the members send the acknowledgement of successful block delete to the host 116 and at 129, the host sends the confirmation of data erase to the requester.
  • anonymization of data with a hash function is known, as discussed.
  • a User ID or Per sonal identifier may be transformed in anonymization data with anonymization engine.
  • the anony- mized data may be aggregated and stored in a central module. Anonymizing prevents the data miner from identifying personal in the data.
  • such an anony mization is applied to blockchains or distributed ledgers.
  • the present disclosure in some embodiments provides the split the data into sensitive part and non-sensitive part and not to store the sensitive part in the blockchains.
  • the computer 130 can be implemented such that it can basically function as any type of net work equipment, e.g. a base station or new radio base station, transmission and reception point, or communication device, such as user equipment, (end) terminal device or the like as described herein.
  • the computer has components 131 to 141, which can form a circuitry, such as any one of the cir cuitries of the network equipments and communication devices, as described herein.
  • Embodiments which use software, firmware, programs or the like for performing the methods as described herein can be installed on computer 130, which is then configured to be suitable for the concrete embodiment.
  • the computer 130 has a CPU 131 (Central Processing Unit), which can execute various types of procedures and methods as described herein, for example, in accordance with programs stored in a read-only memory (ROM) 132, stored in a storage 137 and loaded into a random access memory (RAM) 133, stored on a medium 140 which can be inserted in a respective drive 139, etc.
  • ROM read-only memory
  • RAM random access memory
  • the CPU 131, the ROM 132 and the RAM 133 are connected with a bus 141, which in turn is con nected to an input/ output interface 134.
  • the number of CPUs, memories and storages is only ex emplary, and the skilled person will appreciate that the computer 130 can be adapted and configured accordingly for meeting specific requirements which arise, when it functions as a base station or as user equipment (end terminal).
  • the input/ output interface 134 several components are connected: an input 135, an output 136, the storage 137, a communication interface 138 and the drive 139, into which a medium 140 (com pact disc, digital video disc, compact flash memory, or the like) can be inserted.
  • the input 135 can be a pointer device (mouse, graphic table, or the like), a keyboard, a microphone, a camera, a touchscreen, etc.
  • the output 136 can have a display (liquid crystal display, cathode ray tube display, light emittance diode display, etc.), loudspeakers, etc.
  • a display liquid crystal display, cathode ray tube display, light emittance diode display, etc.
  • loudspeakers etc.
  • the storage 137 can have a hard disk, a solid state drive and the like.
  • the communication interface 138 can be adapted to communicate, for example, via a local area net work (LAN), wireless local area network (WLAN), mobile telecommunications system (GSM, UMTS, LTE, NR etc.), Bluetooth, infrared, etc. It should be noted that the description above only pertains to an example configuration of computer 130. Alternative configurations may be implemented with additional or other sensors, storage de vices, interfaces or the like.
  • the communication interface 138 may support other radio access technologies than the mentioned UMTS, LTE and NR.
  • the communication interface 138 can further have a respective air interface (providing e.g. E-UTRA protocols OFDMA (downlink) and SC- FDMA (uplink)) and network interfaces (implementing for example protocols such as Sl-AP, GTP- U, Sl-MME, X2-AP, or the like).
  • the computer 130 may have one or more antennas and/ or an antenna array. The present disclosure is not limited to any particularities of such proto- cols.
  • the UE 150 is an example of a communication device and the eNB is an example of a base station (i.e. a network equipment), without limiting the present disclosure in that regard.
  • the UE 150 has a transmitter 151, a receiver 152 and a controller 153, wherein, generally, the tech nical functionality of the transmitter 151, the receiver 152 and the controller 153 are known to the skilled person, and, thus, a more detailed description of them is omitted.
  • the eNB 155 has a transmitter 156, a receiver 157 and a controller 158, wherein also here, generally, the functionality of the transmitter 156, the receiver 157 and the controller 158 are known to the skilled person, and, thus, a more detailed description of them is omitted.
  • the communication path 154 has an uplink path 154a, which is from the UE 150 to the eNB 155, and a downlink path 154b, which is from the eNB 155 to the UE 150.
  • the controller 153 of the UE 150 controls the reception of downlink signals over the downlink path 154b at the receiver 152 and the controller 153 controls the transmission of up link signals over the uplink path 154a via the transmitter 151.
  • some embodiments pertain to a commu nication network node for providing data to a distributed ledger, wherein the node has circuitry con figured to provide a user data management part for separating sensitive user data (e.g.
  • the communication network node may be a network equipment, such as a base station, eNodeB or the like, but the node may also be configured as a communication device, such as a user equipment, an (end) terminal device or the like (e.g. mo- bile phone, smartphone, computer, laptop, notebook, etc.) which has circuitry which is configured accordingly.
  • a network equipment such as a base station, eNodeB or the like
  • the node may also be configured as a communication device, such as a user equipment, an (end) terminal device or the like (e.g. mo- bile phone, smartphone, computer, laptop, notebook, etc.) which has circuitry which is configured accordingly.
  • the circuitry is further configured to store the sensitive user data in a data base of the node, hence the node may include the database or it may be connected or associated with the database.
  • the distributed ledger includes (or is) a blockchain, wherein the blockchain may include multiple blocks, the blocks including the non-sensitive user data.
  • the sensitive user data is only stored in a database of the node, while the distributed ledger or blockchain only includes the non-sensitive data.
  • the distributed ledger includes data for mobility as a service.
  • the access to the distributed ledger is granted based on a permission right, wherein the node may be part of a consortium.
  • the consortium may be provided by the mobility service provides, wherein, for example, each node may correspond to or may be associated with one mobility service provider.
  • Some embodiments pertain to a communication network having multiple nodes for providing a dis- tributed ledger, wherein at least one node has circuitry configured to provide a user data manage ment part for separating sensitive user data and non-sensitive user data, and provide the non sensitive user data to the distributed ledger.
  • the communication network may be configured as a telecommunication network, wherein the tele communication network may be configured as a mobile telecommunication network.
  • the nodes of the communication network may be such configured that they provide the distributed ledger.
  • the circuitry is further configured to store the sensitive user data in a database of the node.
  • the distributed ledger may include a blockchain, wherein the blockchain may include multiple blocks, the block including the non-sensitive user data, and wherein the distributed ledger may include data for mobility as a service.
  • the communication net work and its nodes are configured to provide MaaS.
  • access to the distributed ledger is granted based on a permission right, wherein the nodes may be part of a consortium (e.g. a MaaS consortium).
  • personal user data e.g. name or other data which might uniquely identify a user
  • the personal user data may be in- put into the distributed ledger, since, as discussed above, for example for air tickets the passenger name is to known for boarding.
  • the personal user data are pseudonymized by scrambling the sensitive user data, and wherein the personal user data may be anonymized based on applying a hash algorithm.
  • an access control for the non-sensitive data is provided, wherein the access control may be performed on the basis of a key, the key being used for encryption of the non-sensi tive data.
  • the access control provides different keys for different parties, such that dif ferent parties may get different level of access.
  • Different parties may be, for example, the node hav ing the sensitive data, other nodes which have access to the distributed ledger (may be, for example, part of the consortium) and third parties which neither have the sensitive data nor access to the dis tributed ledger or which are not part of the consortium, do not provider MaaS or just need data for data analysis.
  • the access control gives access to the non-sensitive data over an application programming interface.
  • (the) personal user data or the non-sensitive user data can be erased in re sponse to a request from at least one node, wherein the data may be erased by invalidation of a key or by erasing data from the distributed ledger (including erasing all data).
  • the distrib uted ledger may include a blockchain and at least one block may be erased (including the personal data to be erased).
  • Some embodiments pertain to a method for controlling a communication network having multiple nodes for providing a distributed ledger (as discussed herein), the method includes providing a user data management part for separating sensitive user data and non-sensitive user data, and providing the non-sensitive user data to the distributed ledger, as discussed in detail above. All steps discussed herein to be performed, e.g. by the communication network and/ or by the communication network node may be part of the method.
  • the methods as described herein are also implemented in some embodiments as a computer pro gram causing a computer and/ or a processor and/ or circuitry to perform the method, when being carried out on the computer and/ or processor and/ or circuitry.
  • a non- transitory computer-readable recording medium is provided that stores therein a computer program product, which, when executed by a processor, such as the processor described above, causes the methods described herein to be performed.
  • a communication network node for providing data to a distributed ledger, wherein the node comprises circuitry configured to:
  • a communication network comprising multiple nodes for providing a distributed ledger, wherein at least one node comprises circuitry configured to: provide a user data management part for separating sensitive user data and non-sensitive user data, and
  • circuitry is further configured to store the sensitive user data in a database of the node.
  • a method for controlling a communication network comprising multiple nodes for provid ing a distributed ledger, the comprising:

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un noeud de réseau de communication destiné à fournir des données à un registre distribué, ce noeud comprenant des circuits configurés pour : fournir une partie gestion de données utilisateurs destinée à séparer des données utilisateurs sensibles et des données utilisateurs non sensibles, et fournir les données utilisateurs non sensibles au registre distribué.
EP19786835.9A 2018-10-25 2019-10-21 Mobilité préservant la confidentialité, en tant que service pris en charge par une chaîne de blocs Pending EP3844905A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP18202446 2018-10-25
PCT/EP2019/078536 WO2020083822A1 (fr) 2018-10-25 2019-10-21 Mobilité préservant la confidentialité, en tant que service pris en charge par une chaîne de blocs

Publications (1)

Publication Number Publication Date
EP3844905A1 true EP3844905A1 (fr) 2021-07-07

Family

ID=64023960

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19786835.9A Pending EP3844905A1 (fr) 2018-10-25 2019-10-21 Mobilité préservant la confidentialité, en tant que service pris en charge par une chaîne de blocs

Country Status (6)

Country Link
US (1) US11847249B2 (fr)
EP (1) EP3844905A1 (fr)
JP (1) JP2022511393A (fr)
CN (1) CN112805961A (fr)
SG (1) SG11202102420WA (fr)
WO (1) WO2020083822A1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11558906B2 (en) * 2020-02-26 2023-01-17 Westinghouse Air Brake Technologies Corporation Operator authentication with a vehicle using different pathways
US10549202B2 (en) * 2017-10-25 2020-02-04 Sony Interactive Entertainment LLC Blockchain gaming system
EP3739490A1 (fr) * 2019-05-17 2020-11-18 Samsung Electronics Co., Ltd. Serveur et son procédé de commande
CN111475828B (zh) * 2020-05-14 2022-05-13 杭州烽顺科技信息服务有限公司 区块链账本数据的加密方法及装置、解密方法及装置
US11336566B2 (en) 2020-06-29 2022-05-17 Sony Group Corporation Transaction flow management based on operational troubles on a MAAS platform
US11899822B2 (en) * 2020-07-21 2024-02-13 Bank Of America Corporation Private, secure travel system
US11914733B2 (en) * 2021-01-21 2024-02-27 International Business Machines Corporation Timing for user data erasure requests
WO2022184558A1 (fr) * 2021-03-01 2022-09-09 Sony Group Corporation Nœuds de réseau de communication, procédés de fourniture de nœuds de réseau de communication, dispositif terminal, procédé de fonctionnement d'un dispositif terminal, procédés pour réseaux de communication
WO2023165857A1 (fr) * 2022-03-01 2023-09-07 Sony Group Corporation Nœud de réseau de communication, procédé mis en œuvre dans un nœud de réseau de communication, équipement utilisateur, procédé mis en œuvre dans un équipement utilisateur, système de communication, procédé mis en œuvre dans un système de communication
JP7423115B1 (ja) 2023-10-03 2024-01-29 株式会社美利善 Ｎｆｔマーケットプレイスシステム

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007131004A2 (fr) * 2006-05-01 2007-11-15 Patent Acquisition & Licensing Co. génération automatisée de feuilles de présence avec un dispositif récapitulatif automatique
US9202078B2 (en) 2011-05-27 2015-12-01 International Business Machines Corporation Data perturbation and anonymization using one way hash
US8387141B1 (en) * 2011-09-27 2013-02-26 Green Head LLC Smartphone security system
US20140280931A1 (en) * 2013-03-13 2014-09-18 Meetrix Communications, Inc. Controlling access to enterprise software
US20230054446A1 (en) * 2013-11-01 2023-02-23 Anonos Ip Llc Systems and methods for functionally separating geospatial information for lawful and trustworthy analytics, artificial intelligence and machine learning
US20230095123A1 (en) * 2015-04-08 2023-03-30 Portabe Data Corp Systems and Methods for Digitally Signed Contracts with Verifiable Credentials
US10311250B2 (en) 2016-04-05 2019-06-04 Vchain Technology Limited Method and system for managing personal information within independent computer systems and digital networks
US20170331896A1 (en) * 2016-05-13 2017-11-16 De La Rue International Limited Methods and systems for processing assets
CA3027741C (fr) * 2016-06-17 2020-07-21 Jonathan WEIMER Systemes de chaines de blocs et procedes d'authentification d'utilisateur
US10984460B2 (en) * 2016-10-14 2021-04-20 Under Armour, Inc. Medium, method and apparatus for native page generation
US20180197155A1 (en) * 2016-12-12 2018-07-12 Topl, Llc Method and Apparatus for Processing Mobile Payment Using Blockchain Techniques
US11163895B2 (en) * 2016-12-19 2021-11-02 Mitsubishi Electric Corporation Concealment device, data analysis device, and computer readable medium
US20180189501A1 (en) * 2016-12-30 2018-07-05 Kosei Ogawa System and method of transferring data from a cloud-based database to a private network database for long-term storage
US10824746B1 (en) * 2017-01-25 2020-11-03 State Farm Mutual Automobile Insurance Company Systems and methods for controlled access to blockchain data
CN107392040B (zh) * 2017-04-28 2019-08-09 阿里巴巴集团控股有限公司 一种共识验证的方法及装置
US20230108733A1 (en) * 2017-05-24 2023-04-06 3S International, LLC Method of mobilizaing user data in computing network
US20220405750A1 (en) * 2017-05-24 2022-12-22 Nxm Labs, Inc. Network configuration management for networked client devices using a distributed ledger service
US11868991B2 (en) * 2017-08-03 2024-01-09 Liquineq AG System and method for conducting and securing transactions when blockchain connection is unreliable
US20230017855A1 (en) * 2017-08-03 2023-01-19 Liquineq AG Distributed smart wallet communications platform
US11416942B1 (en) * 2017-09-06 2022-08-16 State Farm Mutual Automobile Insurance Company Using a distributed ledger to determine fault in subrogation
US11386498B1 (en) * 2017-09-06 2022-07-12 State Farm Mutual Automobile Insurance Company Using historical data for subrogation on a distributed ledger
CN107770182B (zh) 2017-10-30 2020-09-08 中国联合网络通信集团有限公司 家庭网关的数据存储方法及家庭网关
US11528611B2 (en) * 2018-03-14 2022-12-13 Rose Margaret Smith Method and system for IoT code and configuration using smart contracts
US10803196B2 (en) * 2018-03-30 2020-10-13 Microsoft Technology Licensing, Llc On-demand de-identification of data in computer storage systems
US11876801B2 (en) * 2018-05-11 2024-01-16 Civic Technologies, Inc. User ID codes for online verification
CN108694238A (zh) 2018-05-14 2018-10-23 腾讯科技（深圳）有限公司 基于区块链的业务数据处理方法、装置及存储介质
MX2020013174A (es) * 2018-06-04 2022-08-12 Noah Rafalko Sistema de telecomunicacion y metodo para establecer sesiones de transaccion.
US20200089908A1 (en) * 2018-09-14 2020-03-19 Medhat Faltas System, Method, and Apparatus for Digitally Managing Personal Data
SG11202102642PA (en) * 2018-09-17 2021-04-29 Blockrules Ltd Transaction authentication system and related methods
CA3114317A1 (fr) 2018-09-25 2020-04-02 Sony Corporation Reseau de communication, procede, equipement de reseau et dispositif de communication
US10482554B1 (en) * 2018-10-05 2019-11-19 Capital One Services, Llc Digital negotiation platform

Also Published As

Publication number Publication date
US11847249B2 (en) 2023-12-19
SG11202102420WA (en) 2021-04-29
WO2020083822A1 (fr) 2020-04-30
JP2022511393A (ja) 2022-01-31
US20220035950A1 (en) 2022-02-03
CN112805961A (zh) 2021-05-14

Similar Documents

Publication Publication Date Title
US11847249B2 (en) Privacy-preserving mobility as a service supported by blockchain
US10671733B2 (en) Policy enforcement via peer devices using a blockchain
JP6524347B2 (ja) 情報共有システム
RU2501081C2 (ru) Многофакторная защита контента
US11212347B2 (en) Private content storage with public blockchain metadata
CN111797415A (zh) 基于区块链的数据共享方法、电子设备和存储介质
CN111914293B (zh) 一种数据访问权限验证方法、装置、计算机设备及存储介质
JP2001195548A (ja) 情報携帯処理システム、情報携帯装置のアクセス装置及び情報携帯装置
CN105516110A (zh) 移动设备安全数据传送方法
CN111106930B (zh) 区块链网络构建方法、装置及区块链网络系统
CN105450750A (zh) 智能终端安全交互方法
TWI829219B (zh) 可將取用訊標由區塊鏈子系統移轉給資料請求者裝置的去中心化資料授權控管系統
CN111859443A (zh) 账户级区块链隐私数据访问权限管控方法及系统
US20240064009A1 (en) Distributed anonymized compliant encryption management system
JP2003271782A (ja) 個人情報管理システム
US20240135036A1 (en) Privacy-preserving mobility as a service supported by blockchain
TWI829218B (zh) 可經由第三方服務子系統間接移轉取用訊標的去中心化資料授權控管系統
TWI829216B (zh) 可透過第三方服務子系統轉傳訊標請求的去中心化資料授權控管系統
TWI829217B (zh) 可彈性調整資料授權政策的去中心化資料授權控管系統
US11153299B2 (en) Secure data transport using trusted identities
CN118175172A (zh) 用于提供分布式账本的通信网络节点、通信网络以及方法
TW202101267A (zh) 帳戶資料處理方法及帳戶資料處理系統
US20230089487A1 (en) Communication network, communication network node, user equipment, method
TWI829220B (zh) 可利用智能合約產生並移轉授權訊標的去中心化資料授權控管系統
TWI829221B (zh) 可允許資料請求者裝置查核區塊鏈子系統中的資料授權政策正確性的去中心化資料授權控管系統

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20210329

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SONY GROUP CORPORATION

Owner name: SONY EUROPE B.V.

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230418