COMMUNICATIONS NETWORK, COMMUNICATIONS NETWORK NODE, USER EQUIPMENT, AND METHOD - Patent application

Abstract

The present disclosure generally relates to a communications network for providing a distributed ledger having a plurality of network nodes comprising circuitry configured to provide a traveler profile of a traveler to a roaming mobility service provider in response to a reservation request, and to provide traveler information based on the traveler profile to a transportation operator to enable the traveler to use mobility services of the roaming mobility service provider, the traveler profile provided by a home mobility service provider.

Description

[Technical field]

[0001] The present disclosure generally relates to a communications network for providing a distributed ledger, a communications network, a user equipment, and a method for providing Mobility as a Service. [Background technology]

[0002] It is generally known to distribute a ledger over multiple nodes, such as entities that record digital transactions, e.g. electronic devices, servers, etc. A distributed ledger can be based on the known blockchain technology, on which, for example, the known cryptocurrency Bitcoin is based, but also on the well-known Ethereum project, etc. In general, distributed ledgers may be implemented on other technologies besides blockchain technology, examples of distributed ledger projects that are not based on blockchain include BigchainDB and IOTA, which is a cryptocurrency that uses linked lists.

[0003] Also known as Mobility as a Service (MaaS), users or travelers (passengers) use Mobility as a Service (MaaS) without, for example, renting a car. Mobility as a Service can combine public (e.g. trains, buses, etc.) and private (e.g. car sharing, bike sharing, etc.) transport services from related operators or providers.

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

[0005] While technologies exist for providing distributed ledgers and Mobility as a Service, it is generally desirable to provide communications network nodes, user equipment, communications networks and methods for providing Mobility as a Service. Summary of the Invention

[0006] According to a first aspect, the present disclosure provides a communications network for providing a distributed ledger, the communications network including a plurality of network nodes comprising a circuit, the circuit comprising: The mobile service provider is configured to provide a traveler profile of the traveler to the roaming mobility service provider in response to the reservation request, and to provide traveler information based on the traveler profile to the transportation operator to enable the traveler to use the mobility services of the roaming mobility service provider (the traveler profile being provided by the home mobility service provider).

[0007] According to a second aspect of the present disclosure, the present disclosure provides a method for controlling a communication network to provide a distributed ledger, the method including: providing a traveler profile of a traveler to a roaming mobility service provider in response to a reservation request; and providing traveler information based on the traveler profile to a transportation operator (wherein the traveler profile is provided by a home mobility service provider) to enable the traveler to use mobility services of the roaming mobility service provider.

[0008] According to a third aspect, the present disclosure provides a communications network node having a circuit, the circuit comprising: and configured to provide credentials for the traveler based on the traveler's decentralized identifier (the credentials being generated in the distributed database based on a request to the distributed database, the request being issued in the communications network node) and transmit the credentials to a user equipment to enable the traveler to use mobility services of a roaming mobility service provider.

[0009] According to a fourth aspect, the present disclosure provides a method of controlling a communications network node, the method comprising: The method includes providing credentials for the traveler based on the traveler's distributed identifier (the credentials being generated in the distributed database based on a request to the distributed database, the request being issued in the communications network node), and transmitting the credentials to a user equipment to enable the traveler to use mobility services of a roaming mobility service provider.

[0010] According to a fifth aspect, the present disclosure provides a user equipment comprising a circuit, the circuit comprising: and configured to receive at least one credential of the plurality of credentials in response to a transportation carrier request to the user equipment (the transportation carrier request being based on a roaming mobility service provider reservation request for the traveler to the transportation carrier) and transmit the at least one credential to the transportation carrier to enable the traveler to use the transportation carrier's mobility services.

[0011] According to a sixth aspect, the present disclosure provides an electronic network node including a circuit, the circuit comprising: configured to validate at least one credential of the traveler in response to a request by the traveler to use a mobility service of a roaming mobility service provider; This validation is based on querying a distributed ledger.

[0012] According to a seventh aspect, the present disclosure provides a method of controlling an electronic network node, comprising the step of verifying at least one credential of a traveler in response to a request of the traveler to use a mobility service of a roaming mobility service provider, This verifying step is based on a query of the distributed ledger.

[0013] According to an eighth aspect, the present disclosure provides an electronic network node including a circuit, the circuit comprising: The mobile device is configured to select at least one credential from the plurality of credentials in response to a request from the user equipment and transmit the at least one credential to the user equipment to enable the traveler to use the mobility services of the transportation carrier.

[0014] According to a ninth aspect, the present disclosure provides a method for controlling an electronic network node, comprising: selecting at least one credential from a plurality of credentials in response to a request from a user equipment; and transmitting the at least one credential to the user equipment to enable a traveler to use mobility services of a transportation carrier.

[0015] Further aspects are set out in the dependent claims, the following description and the drawings. [Brief description of the drawings]

[0016] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] Here is a simplified OAuth 2.0 protocol. [Diagram 2] 1 illustrates a roaming mobility service method according to the present disclosure. [Diagram 3] 1 shows a reservation method for roaming mobility services according to the present disclosure. [Figure 4] We present a method for reserving roaming mobility services based on DID-based credentials. [Diagram 5] 1 illustrates a reservation scheme for mobility services of a roaming mobility service provider. [Figure 6] Shown is a Merkle tree. [Figure 7] This presents a blockchain and its general data structure. [Figure 8] This shows the input and output of the blockchain hash function. [Figure 9]This illustrates the PBFT process. [Figure 10] 1 illustrates an embodiment of a general purpose computer. [Figure 11] 1 illustrates an embodiment of a user equipment and an electronic network node. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Before describing the embodiment in detail with reference to FIG. 2, a general description will be given.

[0018] In the case of MaaS, credentials to prove a traveller's permission (authorization) to use mobility services are sometimes provided by a third party.

[0019] For example, a driver's license (eg, as a credential for a car rental service) may be issued by a government transportation agency, and a passport or travel document may be issued by a government.

[0020] Typically, such credentials are stored in, for example, a smartphone application (e.g., a user agent, as described below), and the credentials may be used, if necessary, with the user's consent. Such applications are commonly referred to as Digital Identifier (DI) e-wallets (similar to physical e-wallets that store credit cards, driver's licenses, etc.).

[0021] However, it is recognised that it is desirable to increase privacy in MaaS applications, particularly roaming MaaS services, as privacy may not be secure, for example, in a foreign country or privacy requirements may differ from, for example, one's home country.

[0022] It has therefore been recognised that it is desirable to improve the functionality of such DI e-wallets for roaming mobility services such as air tickets, car sharing etc.

[0023] Below, definitions of some terms are provided, which may be applied in some embodiments (without limiting the disclosure to the definitions provided below). These definitions are only examples provided to enhance understanding of the disclosure, and are only provided because the technology fields of MaaS and distributed ledgers are highly dynamic and definitions may change in the future.

[0024] The term “distributed ledger” is known from Wikipedia, which defines it as “A distributed ledger (also known as a shared ledger or distributed ledger technology, DLT) is a consensus of replicated, shared, and synchronized digital data that is geographically distributed across multiple sites, countries, or institutions, with no central administrator or centralized data storage.”

[0025] Distributed ledgers and a specific example of them, namely blockchain technology, are also discussed further below. More generally, the term distributed ledger is used as a type of database that shares digitally recorded data with multiple nodes in a network. A distributed ledger may consist of a peer-to-peer network. Digitally recorded data may contain a type of information to prove its consistency with previously recorded data on the same database.

[0026] Distributed ledgers can be public and accessible to anyone, but in principle they can also be private and only accessible to permissioned users, and a group of permissioned entities, nodes, people, operators, providers, etc., sometimes referred to as a “consortium,” as explained further below. It is also possible to differentiate access permissions to ledger data for each hierarchical user.

[0027] A distributed ledger can use mechanisms known from blockchain technology, such as that used for Bitcoin, including discovery methods, consensus mechanisms, mechanisms for ensuring data consistency, etc. The consensus mechanism ensures that all nodes or a certain number of nodes, typically electronic devices, that have a copy of the distributed ledger reach a consensus on the contents of the distributed ledger. There are many consensus mechanisms, including the so-called proof-of-work mechanism, which is a kind of cryptographic puzzle and ensures, for example, that old blocks in the blockchain cannot be (easily) altered. For example, the mining process of the Bitcoin blockchain uses proof of work.

[0028] In a distributed ledger or blockchain, the approval process that creates a consensus on data updates on the blockchain among participating nodes, called the mining process, can achieve irreversibility of the sequence of transactions recorded on the blockchain by including previously recorded data in the approval data. Such a mining process implements a distributed time stamp server for new transaction blocks. In Bitcoin (and therefore in some embodiments), the mining process is based on the SHA256 hash function. While the input of the hash function depends on the current block of the blockchain and the new block of transactions to be added to the blockchain, the nodes of the blockchain involved in the mining process search for a hash output that has predefined properties.

[0029] Proof-of-work computations based on hash functions need not be useful in themselves, except as they are needed to implement irreversibility in a distributed ledger.

[0030] Moreover, it is generally known to use the blockchain to store various data: for example, images, videos, measurements, and text files can be recorded on the blockchain in the form of transactions.

[0031] The term "Mobility as a Service (MaaS)" describes a shift away from personally owned modes of transportation and towards mobility solutions consumed as a service. This is made possible by combining transport services from public and private transport providers through a unified gateway to create and manage trips, which users can pay for through a single account. Users can pay per trip, or pay a monthly fee for a limited distance. The key concept behind MaaS is to provide mobility solutions to travelers based on their travel needs. It is also known from Wikipedia, which defines it as "mobility as a service (MaaS)."

[0032] The term "mobility service provider" is a catch-all name for any type of service provider MaaS. In some embodiments, the mobility service provider is a transport operator, typically a rail company, bus / coach, tram and taxi, car sharing, ride sharing, bike sharing, etc. Some mobility service providers may not provide the actual transportation, but may only provide the booking / arrangement services comparable to a travel agency or online booking site.

[0033] The term "Traveler (Passenger)" refers to a person who has a service agreement with a Home Mobility Service Provider, i.e., who is a customer of a Home Mobility Service Provider (defined below).

[0034] "Mobility Service Provider" (also referred to as "MaaS Service Provider") is a broader term of the terms "Home Mobility Service Provider" and "Roaming Mobility Service Provider" (defined below) and refers to an operator, society, enterprise or other entity that provides mobility services in a specific territory.

[0035] The term "home mobility service provider" means a mobility service provider located or operating in a fixed area (e.g., country, city) and may be a mobility service provider with which a traveler has a contract, for example, for a pass, ticket, subscription, etc. This provider may in some embodiments be multiple service providers as well.

[0036] The term "roaming mobility service provider" refers to other mobility service providers with which the traveler does not have a direct contract, subscription or otherwise. Thus, a traveler may use the mobility services of a roaming mobility service provider, but the process of purchasing a pass, ticket, or using the mobility services of the roaming mobility service provider may be handled through the home mobility service provider.

[0037] The term "User" refers to a traveller seeking to use a roaming mobility service provider.

[0038] The term "user" may also refer to a traveler's terminal device (eg, a smartphone).

[0039] The term "user agent" means software, applications, etc. running on a traveler's terminal device, which is configured to handle DIDs (see below), credentials (see below), etc. For example, a MaaS application (e.g. from a mobility service provider) may act as a user agent.

[0040] A Distributed Identifier (DID) resolver may refer to a server (or other information system) that looks up a DID document in response to validation (authentication), such as via a DID (see below).

[0041] Credentials may refer to evidence of status, rights, membership, etc., recognized by an issuer, MaaS provider, etc. For example, a user may prove their MaaS subscription membership (e.g., to a home mobility service provider) with credentials (e.g., to a roaming mobility service provider).

[0042] In some embodiments, the term "public key cryptography" is understood to mean, as defined by Wikipedia (https: / / en.wikipedia.org / wiki / Public-key_cryptography), "Public key cryptography, or asymmetric cryptography, is any cryptographic system that uses a pair of a widely distributed public key and a private key known only to its owner." This accomplishes two functions: authentication, to verify that the holder of the paired private key sent the message, and encryption, so that only the holder of the paired private key can decrypt messages encrypted with the public key." On the other hand, "two of the most well-known uses of public key cryptography are public key encryption, where a message is encrypted with the recipient's public key. The message cannot be decrypted by anyone other than those who do not have the matching private key, and therefore cannot be decrypted except by those who are presumed to be the owner of that key and the person associated with the public key. This is used in an attempt to ensure confidentiality." It also states that "A digital signature, when a message is signed with the sender's private key, can be verified by anyone with access to the sender's public key. This verification proves that the sender has access to that private key and is therefore likely to be the person associated with that public key. This also ensures that the message has not been tampered with, since the signature is mathematically bound to the message that was originally created. It also ensures that any other message, no matter how similar it is to the original, will in fact fail verification."

[0043] The term “personal data” may be understood in some embodiments as having the following meaning (see exemplarily https: / / gdpr-info.eu / art-4-gdpr / ): “(1) ‘Personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identified natural person can be identified, directly or indirectly, in particular by reference to an identifier such as that natural person’s name, an identification number, location data, an online identifier or to the physical, physiological, mental, economic, cultural or social identity of that natural person;

[0044] In one embodiment, the abbreviation AAA may refer to "authentication, authorization, and accounting" in computer networks or network services, as commonly known in the security framework of information and communication technology (ICT).

[0045] Authentication refers to checking whether a user (or, in the context of this disclosure, a traveler) is a legitimate user of a network, network service, or system. For example, a MaaS service provider (e.g., mobility service provider, transport operator) may check the identity and service subscription status of a user / traveler when the user / traveler attempts to use a MaaS service.

[0046] Authorization means identifying the specific service (or services) that an authenticated user / traveler is permitted to use. For example, the MaaS service provider can check the user's contract type, service type, and determine the user / traveler's permitted services. For example, a user / traveler may be allowed to use train services but not taxi services, or may be allowed to use trains but denied to use taxis.

[0047] Accounting refers to the recording of user behavior and services used (e.g., the duration of service use, frequency of service use, etc.). For example, when a traveler uses MaaS services such as booking, riding, etc., the traveler can store this record.

[0048] The term "Identity Hub" means a server / storage facility for storing one or more credentials of a Traveler.

[0049] The term "Digital Identity e-Wallet" or "SSI e-Wallet" refers to an application that stores at least one DID-based credential.

[0050] In some embodiments, an authorization framework such as OAuth, OAuth 2.0, or the like, as known from the Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749, may be utilized.

[0051] Such an authorization framework may be used by third-party applications, for example, an application on a terminal device (e.g., a smartphone) may reuse a social network service (SNS) account for third-party server access. The authorization server can then perform authorization on behalf of the third party and provide a token that allows the (client) application to access the data protected by the provided token, as further discussed with reference to Figure 1, which shows a simplified OAuth 2.0 protocol. For more information, see https: / / tools.ietf.org / html / rfc6749 domain.

[0052] The top part of Figure 1 depicts the connection of an end user 1 using a client application 2, which in turn accesses an authorization server 3.

[0053] At the bottom of Figure 1, an authorization method 4 is depicted. A client application 5 (which may be the same as client application 2) queries a resource owner 7 (e.g., end user 1) at 6 for permission to reuse an account.

[0054] At 8, the resource owner 7 enables the reuse such that at 9 the client application 5 provides an authorization grant to an authorization server 10 where the SNS account is stored.

[0055] At 11, the authorization server sends an access token for access to a third party server 12, which is a resource server that stores the protected data.

[0056] The client application 5 requests 13 data protected by the access token received from the third party server 12 .

[0057] At 14 , the third party server 12 sends the requested data to the client application 5 .

[0058] Such methods are also called social login, as explained in Figure 1 (see also https: / / en.wikipedia.org / wiki / Social_login). Social login can provide authorization for third-party services using a common SNS account.

[0059] Thus, some embodiments relate to a communications network node having circuitry configured to request a home mobility service provider to enable roaming mobility services for a traveler located in a mobility service area of ​​the roaming mobility service provider.

[0060] A communications network node may be a computer, a server, a terminal device, etc. Furthermore, a plurality of such components may be envisaged (e.g. several servers which may be coupled to a terminal device, etc.).

[0061] The request may be issued in response to detection of a traveler within a mobility service area of ​​a roaming mobility service provider.

[0062] Further explanation will now be given with reference to FIG.

[0063] FIG. 2 illustrates a roaming mobility services method 20 in accordance with the present disclosure.

[0064] The home mobility service provider 21 sends roaming mobility service assistance information at 22 to the traveler 23 for roaming mobility service arrangement. The assistance information includes, in this embodiment, the name of the roaming mobility service provider 24 and the mobility service area of ​​the roaming mobility service provider 24.

[0065] For roaming mobility service detection, a sensor 25 (eg, a GNSS sensor) on the traveler's 23 mobile phone detects 26 that the traveler 23 enters a predefined area (eg, via geofencing).

[0066] Further, the traveller 23 selects a roaming mobility service at 27 with the mobile phone user interface displaying the corresponding application.

[0067] At 28 , an application on the mobile phone requests roaming mobility services from a roaming mobility service provider 24 .

[0068] To authenticate / authorize the user to use the mobility services of the roaming mobility service provider 24, the roaming mobility service provider 24 sends a request at 29 to the home mobility service provider 21 to confirm the subscription of the traveler's 23 service at the home mobility service provider 21.

[0069] The home mobility service provider 21 then checks whether a user account exists for the traveller 23 and thereby checks authentication at 30 .

[0070] Furthermore, the home mobility service provider 21 checks the permitted services of the roaming mobility service and thereby checks authorization at 31 .

[0071] At 32 , the home mobility service provider 21 sends the authorized mobility services of the traveler 23 to the roaming mobility service provider 24 .

[0072] At 33, the roaming mobility service provider 24 sends a notification to the traveler 23 that roaming has been approved, and at 34, the roaming mobility service provider 24 starts roaming services according to the received result.

[0073] The detection may be based on at least one of a Mobility Country Code (MCC), geofencing, an external trigger, and a booking history.

[0074] The MCC may be provided, for example, by a mobile phone network and indicate a country or region that a terminal device (e.g., a mobile phone) may be located in. Such a mobile network may transmit (or broadcast) the MCC, and when the terminal device is in an operational state, the terminal device may be configured to receive the MCC and identify the country in which it is located.

[0075] The terminal device may be configured to detect that a user (eg, an owner of the terminal device) is in a country other than his or her home country based on the received MCC. A relevant MaaS client application (e.g. of a local mobility service provider in the current country) may be launched on the terminal device, and the terminal device may be configured to notify the mobility service provider, thereby requesting roaming mobility services from the local mobility service provider, so that the local mobility service provider becomes the roaming mobility service provider for the user.

[0076] Geofencing may be based on the positioning capabilities of the terminal device, which in one embodiment may be a Global Navigation Satellite System (GNSS) and may be configured to determine the location of the user.

[0077] A home mobility service provider may provide a geolocation database to a terminal device, where such database may include authorized roaming service areas. When the user (or the terminal device) is in an authorized roaming service area, the terminal device may trigger the launch of the relevant MaaS application as described above.

[0078] The external trigger may refer to a beacon signal, such as a Bluetooth® beacon, a Bluetooth Low Energy (BLE)® beacon, or a Near Field Communication (NFC) signal.

[0079] For example, the trigger point may be located at a boarding gate, a railway station, a national gateway, an area, a zone, etc., and the trigger point may be configured to emit one or more beacon signals without limiting the disclosure to the above-mentioned beacon signals (e.g., a Wi-Fi signal may also be deemed sufficient).

[0080] If a traveler (user) is close enough to a trigger point and the traveler's terminal device can receive the beacon signal, the terminal device can be configured to determine the country, region, area, etc. based on the beacon signal.

[0081] Alternatively or additionally, the terminal device may be configured to request further information. For example, the terminal device may send a message (e.g., SMS) requesting the roaming mobility service provider. Such an embodiment may be envisaged when the energy of the received beacon signal is below a predefined threshold, when the amount of information in the beacon is limited, etc.

[0082] Booking history may refer to keeping track of a traveler's previous bookings. For example, a roaming mobility service provider may store a travel record of a traveler (e.g., air travel to go internationally). For example, a traveler may book flights, train travel, etc. with a roaming mobility service provider. The roaming mobility service provider may store this reservation as a reservation record in an application on the traveler's terminal device. At the booked travel date and time, the application may initiate the roaming mobility service.

[0083] It is recognized that social login is applicable to MaaS roaming services.

[0084] Thus, in some embodiments, the circuitry is further configured to perform a social login to a roaming mobility service provider.

[0085] However, in some embodiments, social login may not be suitable for MaaS services: for example, social login may rely on an identifier provided by a particular company, so that the company knows (directly or indirectly) each request of a traveler to use a MaaS service. Therefore, for privacy reasons and from the MaaS service provider's perspective, access to trip records may need to be restricted for third parties.

[0086] It is therefore recognised that the MaaS Identifier may be controlled by individual decentralised issuers.

[0087] Thus, in some embodiments, the identifier is a decentralized identifier.

[0088] A Decentralized Identifier (DID) can provide a Distributed Public Key Infrastructure (DPKI). A definition of a DID can be found, for example, by the Centralized Globally Unique Identifiers World Wide Web Consortium (W3C) (see also https: / / w3c-ccg.github.io / did-primer / and / or https: / / query.prod.cms.rt.microsoft.com / cms / api / am / binary / RE2DjfY).

[0089] In some embodiments, such decentralized identifiers are used to verify, identify, authorize, and authenticate travelers to mobility service providers.

[0090] A DID can be used, for example, to provide a self-sovereign identifier, and thus in some embodiments the identifier is a self-sovereign identifier.

[0091] Additionally, a DID document may refer to data (electronic documents) that describe how to use a DID in a DID resolver. A DID document may contain, for example, a DID, a public key (or multiple public keys), an authentication method, a type of service (service endpoints), a timestamp, a signature, etc.

[0092] An SSI can be defined as a portable digital identifier with a lifetime independent of any centralized authority, which may further meet the requirements of persistence, global resolvability, cryptographic verifiability and decentralization (see also https: / / w3c-ccg.github.io / did-primer / ).

[0093] Thus, while traditional identifiers may be provided by a centralized entity or authority (e.g., a government) and an SNS service provider, in the case of an SSI, no such authority is required.

[0094] Popular SSI standards such as Hyperledger Indy may be used and applied to MaaS roaming services in accordance with the present disclosure.

[0095] FIG. 3 illustrates a method 40 for reserving roaming mobility services with a roaming mobility service provider 24 .

[0096] It is assumed here that roaming has already been initiated, for example, by the preceding method 20 discussed with respect to FIG. 2, without limiting the disclosure in that respect.

[0097] Also, the home mobility service provider 21 stores a profile of the traveler 23 including personal data such as passport information, whereas the roaming mobility service provider 24 does not have a profile of the traveler 23 .

[0098] At 41, the traveler 23 issues a reservation request, which is sent at 42 to the roaming mobility service provider 24. The roaming mobility service provider sends the reservation request to a carrier 44.

[0099] In this embodiment, the roaming mobility service provider 24 is a superior society to the transport operators 44. For example, in the mobility service area of ​​the roaming mobility service provider, there may be multiple transport operators, e.g., different taxi, railroad, bus companies, etc., but there may be a single mobility service provider (which is the roaming mobility service provider 24 in this embodiment) that centrally manages reservation requests to the transport operators.

[0100] The booking request is in this embodiment for a train trip, however, any kind of mobility as a service can be envisaged according to the present disclosure, for example air trips, sea trips, taxi trips, carpooling, etc.

[0101] The transportation provider 44 requests (advanced) traveler information at 45, which in this embodiment is the traveler's 23 name, date of birth, gender, and passport information, without limiting this disclosure in that respect.

[0102] Based on the request at 45, the roaming mobility service provider 24 requests a profile of the traveler 23 from the home mobility service provider 21 at 46, and the home mobility service provider 21 sends the profile of the traveler 23 to the roaming mobility service provider 24 at 47.

[0103] At 48, the roaming mobility service provider 24 transmits the advanced traveler information to the transport operator 44. Based on this, the transport operator 44 sends the reservation result to the roaming mobility service provider 24, which forwards the reservation result to the traveler 23 at 50 so that the reservation is completed at 51.

[0104] Thus, in this embodiment, it is possible to avoid permanent storage of personal data at the roaming mobility service provider and / or the transport operator. Furthermore, it is possible to ensure that the booking at the transport operator is simplified by coordinating the booking via the roaming mobile service provider 24.

[0105] Thus, as discussed with respect to FIG. 3, some embodiments relate to a communications network for providing a distributed ledger that includes a plurality of network nodes comprising a circuit, the circuit comprising: The mobile service provider is configured to provide a traveler profile of the traveler to the roaming mobility service provider in response to the reservation request, and to provide traveler information based on the traveler profile to the transportation operator to enable the traveler to use the mobility services of the roaming mobility service provider (the traveler profile being provided by the home mobility service provider).

[0106] In some embodiments, the distributed ledger is based on a blockchain.

[0107] In some embodiments, the traveler profile includes personal data.

[0108] In some embodiments, the traveler profile includes personal data.

[0109] In some embodiments, traveler information refers to personal data.

[0110] In some embodiments, the traveler information includes at least one of the traveler's name, date of birth, gender, and passport information.

[0111] Some embodiments relate to a method of controlling a communications network to provide a distributed ledger as discussed herein, comprising providing a traveler profile of the traveler to a roaming mobility service provider in response to a reservation request, and providing traveler information based on the traveler profile to a transportation operator (wherein the traveler profile is provided by the home mobility service provider) to enable the traveler to use mobility services of the roaming mobility service provider.

[0112] However, in some embodiments it may be required (e.g., for privacy reasons) that personal data is not disclosed to or retained by third parties (e.g., GDPR (General Data Protection Regulation)).

[0113] It is therefore recognised that it is appropriate to use decentralised identifiers for generating credentials, which may meet privacy requirements.

[0114] Furthermore, it has been recognized that it is sufficient with respect to reducing storage space on user equipment to store credentials in a decentralized manner, e.g., in an electronic network node such as an Identity Hub, as discussed with respect to Figure 4. In one embodiment, a Decentralized Identifier E-Wallet (DI E-Wallet) is provided by such an Identity Hub.

[0115] For example, credentials displayed in the DI e-wallet may correspond to travel documents, passports, visas, driver's licenses, insurance policies, insurance cards, airline mileage cards, rail mileage cards, credit cards, debit cards, or other membership information.

[0116] Thus, some embodiments relate to a communications network node having circuitry configured to provide credentials for a traveler based on a distributed identifier for the traveler (the credentials being generated in a distributed database based on a request to the distributed database, the request being issued in the communications network node) and to transmit the credentials to user equipment to enable the traveler to use mobility services of a roaming mobility service provider.

[0117] As mentioned above, further explanation is given with reference to FIG.

[0118] FIG. 4 illustrates a method 60 for subscribing roaming mobility services based on DID-based credentials.

[0119] The user agent 23 (controlled by the traveller according to the previous embodiment, hence the same reference number) communicates at 61 the personal details of the traveller to a third party 62. The third party may be any authority over the traveller, such as for example a government. Furthermore, at 63 the third party 62 is informed of the traveller's DID.

[0120] At 64, the third party requests issuance of a DID-based credential from a distributed system (e.g., distributed ledger, blockchain), which is issued at 66 and sent to the third party 62 at 67.

[0121] The third party 62 sends the credentials at 68 to the user agent 23 on an identity hub 70 configured to provide a DI e-wallet, and the user agent 23 issues storage of the credentials at 69 .

[0122] In some embodiments, the circuitry is further configured to provide a decentralized identifier electronic wallet, as discussed.

[0123] In some embodiments, the credentials are represented in a decentralized identity electronic wallet, as discussed.

[0124] Some embodiments relate to a method of controlling a communications network node as discussed herein, the method comprising: The method includes providing credentials for the traveler based on the traveler's distributed identifier (the credentials being generated in the distributed database based on a request to the distributed database, the request being issued at a communications network node), and transmitting the credentials to a user equipment to enable the traveler to use mobility services of a roaming mobility service provider.

[0125] Additionally, some embodiments relate to a user equipment having a circuit, the circuit comprising: and configured to receive at least one credential of the plurality of credentials in response to a transportation carrier request to the user equipment, the transportation carrier request being based on a roaming mobility service provider reservation request for the traveler to the transportation carrier, and to transmit the at least one credential to the transportation carrier to enable the traveler to use the transportation carrier's mobility services.

[0126] The user equipment is configured to function as a user agent in accordance with the present disclosure, as further described with respect to FIG. 5, and may be a mobile phone, a smartphone, a tablet, a smart watch, smart glasses, a computer, or the like.

[0127] FIG. 5 illustrates a method 80 for reserving mobility services of a roaming mobility service provider 24 .

[0128] Here, the roaming service has already been initiated and the associated credentials have already been generated.

[0129] The user agent 23 requests a reservation at 81 with the roaming mobile service provider 24 , which forwards the reservation request at 82 to the carrier 44 .

[0130] In response, the carrier 44 requests advanced traveler information at 83, as previously discussed.

[0131] For privacy reasons, in this embodiment, without limiting this disclosure, the traveler is asked for consent to reveal traveler information, so that after the traveler gives his / her consent, the necessary credentials at 85 are requested by the identity hub 70. This is necessary because, in this embodiment, the user agent is configured to recognize that credentials are required along with the requested traveler information. For example, if the traveler plans to go to a country that requires at least one visa and pre-registration (e.g., US ESTA), the user agent is configured to retrieve these documents as credentials in addition to the traveler's and / or DID's passport information.

[0132] For example, the user agent may be configured to connect the user equipment to the identity hub over a secure connection (e.g., over the Internet). In other embodiments, the user equipment (or user agent) may be configured to store the credentials in secure storage.

[0133] However, in this embodiment, the identity hub 70 is configured to select relevant credentials based on the request at 86. Thus, the request at 85 includes a reservation request and necessary traveler information. It may be sufficient for the identity hub to transmit only partial data sufficient for the traveler to fulfill the conditions for using the mobility services of the roaming mobility service provider or the transport operator, respectively.

[0134] The relevant credentials are transmitted at 87 to the user agent 23. Note that in general, it is also possible for a single credential to be requested, selected and transmitted.

[0135] At 88, the user agent 23 sends the credentials to the carrier 44, which verifies the credentials at 89 by checking the expiration date of each credential, revocation of each credential, travel requirements, and entry conditions of the destination country.

[0136] At 90 , the carrier transmits the verification result of 89 to the user agent 23 .

[0137] In one embodiment, this verification is based on a query to a centralized database.

[0138] In some embodiments, the centralized database is assigned to at least one issuer (eg, a shipping carrier, a third party) of at least one credential.

[0139] Thus, one issuer may similarly provide multiple credentials, but one credential may also be provided by multiple issuers.

[0140] However, in some embodiments, validation is based on querying a distributed ledger (i.e., a distributed database).

[0141] In some embodiments, the distributed ledger is based on a blockchain.

[0142] In some embodiments, the verification is based on a hash function.

[0143] Hash functions are commonly known in the context of blockchains (or distributed ledgers in general), as discussed with respect to FIG.

[0144] FIG. 6 shows the commonly known Merkle tree.

[0145] The actual data aa, ab, ba, and bb are hashed to hash aa, ab, ba, and bb, respectively, so that the previous actual data data structure is made compact (e.g., 256 bits in size, depending on the hash function used). Furthermore, hashes are irreversible, i.e. the original (real) data cannot be reconstructed from the hashed data.

[0146] From hashes aa and ab, hash a is hashed (hash a is called the tier hash for hashes ab and aa), from hashes ba and bb, hash b is hashed, from hashes a and b, the root hash is hashed (this is the tier hash that hashes a and b).

[0147] Therefore, in the case of MaaS, privacy conditions can be met by verifying the credentials based on a hash function, i.e. a Merkle tree, respectively.

[0148] According to this disclosure, the validation is based on Merkle trees, as discussed.

[0149] For example, a passport issuer may convert each passport entry into its own hash value, then calculate the hash of each hierarchy.The latest root hashes and intermediate values ​​can then be stored in a distributed database (system, ledger, etc.).

[0150] If an issuer needs to revoke a credential, the issuer deletes the credential and recalculates the root hash based on the private information. Additionally, the issuer may store the root hash and intermediate hash values.

[0151] When a verifier (e.g., a transportation company) needs to verify a credential (e.g., corresponding to actual data 11 in FIG. 6), the verifier may query (query) the traveler for hash 11 from the distributed system.

[0152] Additionally, the verifier may retrieve hash12 and use hash11 (calculated from actual data 11) and hash12 to calculate hash1. Additionally, the verifier may retrieve hash2 from the distributed system so that the root hash can be calculated from hash1 and hash2.

[0153] If the credentials are valid, the root hash calculated by the verifier is identical to the root hash stored in the distributed system.

[0154] If the credential has been revoked by the issuer, the calculated root hash and the stored root hash will differ.

[0155] Verifying credentials based on a distributed ledger (or based on a hash) can significantly reduce the computational burden compared to a centralized database that requires storing and transmitting the entire credential. The computational load is typically expressed as log 2 The number of credentials is reduced by (N), where N is the number of credentials.

[0156] Additionally, privacy is protected since personal data is hashed and there is no need to read the personal data.

[0157] Accordingly, some embodiments relate to an electronic network node that includes a circuit as discussed herein, the circuit comprising: configured to validate at least one credential of the traveler in response to a request by the traveler to use a mobility service of a roaming mobility service provider; This validation is based on querying the distributed ledger.

[0158] The electronic network nodes may be controlled by a mobility service provider, such as a roaming mobility service provider, a home mobility service provider, or a transportation operator.

[0159] In some embodiments, the distributed ledger is based on a blockchain, as discussed herein.

[0160] In some embodiments, the verification of at least one credential is based on a hash function, as discussed herein.

[0161] In some embodiments, validation of the at least one credential is further based on a Merkle tree, as discussed herein.

[0162] Some embodiments relate to a method of controlling an electronic network node as discussed herein, comprising verifying at least one credential of a traveler in response to a request by the traveler to use a mobility service of a roaming mobility service provider, the verifying being based on a query of a distributed ledger.

[0163] Some embodiments relate to an electronic network node including a circuit as discussed herein with respect to FIG. The mobile device is configured to select at least one credential from the plurality of credentials in response to a request from the user equipment and transmit the at least one credential to the user equipment to enable the traveler to use the mobility services of the transportation carrier.

[0164] The electronic network nodes may be controlled or configured by an identity hub (e.g., a server), as discussed.

[0165] Some embodiments relate to a method of controlling an electronic network node, as discussed herein, that includes selecting at least one credential from a plurality of credentials in response to a request from a user equipment, and transmitting the at least one credential to the user equipment to enable a traveler to use mobility services of a transportation carrier.

[0166] In the following, the blockchain and its general data structure are described with reference to Figure 7. The blockchain features of this embodiment are network / topology, consensus algorithm, hash function, participation authentication, scalability / block structure and performance.

[0167] FIG. 7 shows the general structure of a blockchain 100. Blockchain 100 includes a chain of multiple data blocks 101a, 101b, and 101c, where block 101b is the current block (block #N), block 101a is the previous block (block #N-1), and block 101c is the future or subsequent block (block #N+1). Each block contains the result of the hash function of the previous block, a main data structure, the input value to the hash function of the current block and the result of the hash function; the hash function result of the current block (101b) is always used as input to the next block (101c).

[0168] Each block also contains a “nonce” (a disposable number used once), which is a one-time random number for secure blockchain processing and can prevent replay attacks. For example, if an attacker copies previously sent data and reuses the copied data to spoof a message, the receiver can detect the spoofed communication because the next data must be used with a different "nonce," sometimes called a "nonce" in cryptography.

[0169] Additionally, a timestamp may be inserted into each of blocks 101a, 101b, and 101c. Blockchain 100 is an example of a distributed ledger that may be used, for example, to provide MaaS in some embodiments.

[0170] FIG. 8 illustrates the inputs and outputs of a hash function used, for example, in the blockchain 100 of FIG.

[0171] In general, a hash function is any function that can be used to map input data to output data in a particular algorithm. The input data can be large and variable in size, and conversely, the output data can be compact and have a fixed size. A known (and well-known) algorithm 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).

[0172] The inputs to the hash function are the previous hash output, a nonce, and the body of data in the current block (e.g., block 101b in FIG. 7). The output of the hash function is a unique response value to the input values. If someone tries to tamper with the body of data, the output of the hash function will be inconsistent.

[0173] The distributed ledger (blockchain) embodiments of this 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 spoofing and hardware failures.

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

[0175] In some embodiments, a permissioned blockchain is used, where a relatively small number of permissioned blockchain nodes are responsible for consensus (validating blocks).

[0176] FIG. 9 illustrates a process 110 for PBFT.

[0177] The leader node (also called a non-endorsing peer) requests other nodes to validate the blockchain in step 111. In step 112, each requested node (endorsing peer) checks the validity of the blockchain using a hash function and indicates the result to the other nodes in step 113. A node receives validity results from multiple other peers and if it receives a result that is more valid than a predefined criterion, it checks for blockchain consensus, step 114. If there is consensus, then in step 115 the node writes / finishes the blockchain. The leader peer checks the overall progress of the validation in the other nodes and terminates the blockchain procedure in step 116.

[0178] For resiliency, the total number of nodes exceeds 3f+1 in some embodiments, where f is the number of tolerated failed nodes. For example, if f=1, there are 4 nodes in total; if f=3, there are 10 nodes in total, and so on.

[0179] In some embodiments, PBFT as described herein includes a permissioned blockchain for mobility services blockchain, providing at least in part the following features:

[0180] In terms of security, PBFT, in some embodiments, offers a small risk of 51% attacks, which are common to cryptocurrencies since the permissions of the peers responsible for consensus must be trusted. Regarding privacy, end users do not have access to the entire blockchain since only the mobility service provider processes the entire blockchain at the (peer) nodes (due to the permission-based blockchain and end users do not have permission to access the entire blockchain). In terms of performance, the processing time for consensus is in some embodiments very short due to the small number of peers with high performance. In terms of flexibility, the block size and format of the blockchain are in some embodiments flexible compared to public blockchains.

[0181] One embodiment of a general purpose computer 130 is described below with reference to FIG. The computer 130 may be implemented such that it can essentially function as any type of network equipment, e.g. a network node, an identity hub, part of a distributed database, a base station or new radio base station, a transmission / reception point, or a communications device such as user equipment, (end) terminal device, etc. The computer has components 131-141 that can configure circuitry such as any one of the circuitry of a network apparatus and a communication device as described herein.

[0182] The embodiments using software, firmware, programs, etc. to perform the methods described herein are then installed on computer 130 configured appropriately for the particular embodiment.

[0183] The computer 130 has a CPU 131 (Central Processing Unit), which can execute various types of procedures and methods described herein according to a program stored, for example, in a read-only memory (ROM) 132, stored in a storage 137, loaded into a random access memory (RAM) 133, or stored in a recording medium (media) 140 inserted in a respective drive 139.

[0184] The CPU 131, ROM 132 and RAM 133 are connected by a bus 141, which is connected to an input / output interface 134. Those skilled in the art will appreciate that the number of CPUs, memory and storage are merely exemplary, and that the computer 130 will be adapted and configured to meet the particular requirements that arise when functioning as a base station or as user equipment (end terminal).

[0185] The input / output interface 134 is connected to several components such as an input section 135, an output section 136, storage 137, a communication interface 138, and a drive 139 into which a recording medium 140 (such as a CD, a digital video disk, a compact flash (registered trademark) memory, etc.) can be inserted.

[0186] The input unit 135 may be a pointer device (such as a mouse or a pen tablet), a keyboard, a microphone, a camera, a touch screen, or the like.

[0187] The output unit 136 may include a display (such as a liquid crystal display, a cathode ray tube display, or a light emitting diode display), a speaker, and the like.

[0188] Storage 137 may include a hard disk, a solid state drive, or the like.

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

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

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

[0192] An embodiment of user equipment UE 150 and eNB 155 (or NR eNB / gNB), as well as a communication path 154 between UE 150 and eNB 155, used to implement embodiments of the present disclosure, is described with reference to FIG. 11. UE 150 is an example of a communications device, and eNB is an example of a base station (eg, network equipment), although this disclosure is not limited in this respect.

[0193] The UE 150 has a transmitter 151, a receiver 152 and a controller 153, where in general, the technical functionality of the transmitter 151, the receiver 152 and the controller 153 is known to those skilled in the art, and therefore a more detailed description thereof will be omitted.

[0194] The eNB 155 has a transmitter 156, a receiver 157 and a controller 158, and again in general, the functionality of the transmitter 156, the receiver 157 and the controller 158 are known to those skilled in the art and therefore a more detailed description thereof will be omitted.

[0195] The communication path 154 includes 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 .

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

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

[0198] The methods described herein are, in some embodiments, also implemented as a computer program that, when executed on a computer and / or processor and / or circuitry, causes the computer and / or processor and / or circuitry to perform the methods. In some embodiments, a non-transitory computer readable storage medium storing a computer program product that, when executed by the above-mentioned processor, causes the method described herein to be performed.

[0199] It should be understood that embodiments of the present invention describe methods with exemplary ordering of method steps, however, the particular ordering of method steps is provided for illustrative purposes only and should not be construed as binding. For example, the ordering of 22 and 26 in the embodiment of Figure 2 may be swapped. Also, the order of 61, 63, and 64 in the embodiment of Figure 4 may be swapped. Furthermore, the ordering of 84 and 85 in the embodiment of Figure 5 may be swapped. Other variations in the ordering of method steps will be apparent to those skilled in the art.

[0200] It should be noted that the division of UE 150 into units 151-153 is for illustrative purposes only, and the present disclosure is not limited to any particular division of functionality among the particular units. For example, UE 150 may be implemented by a respective programmed processor, field programmable gate array, or the like.

[0201] All units and entities described in this specification and claimed in the accompanying claims are implemented as integrated circuit logic, for example on a chip, unless otherwise stated, and the functions provided by such units and entities are implemented by software, unless otherwise stated.

[0202] In so far as the embodiments of the present disclosure described above are implemented, at least in part, using software-controlled data processing apparatus, it will be understood that computer programs providing such software control, and the transmission, storage, or other media on which such computer programs are provided, are contemplated as aspects of the present disclosure.

[0203] The present technology may be configured as follows. (1) A communications network for providing a distributed ledger, the network network including a plurality of network nodes having a circuit, the circuit comprising: Providing a traveler profile for the traveler to the roaming mobility service provider in response to the reservation request; configured to provide traveler information based on the traveler profile to a transportation operator to enable the traveler to use mobility services of the roaming mobility service provider; The traveler profile is provided by a home mobility service provider. Communications network. (2) The distributed ledger is based on blockchain 10. The communications network according to claim 1. (3) The traveler profile contains personal data. A communications network according to (1) or (2). (4) The traveler information indicates the personal data. (3) A communication network as described above. (5) The traveler information includes at least one of the traveler's name, date of birth, gender, and passport information. A communication network according to any one of (1) to (4). (6) A method of controlling a communications network for providing a distributed ledger, comprising: providing a traveler profile of the traveler to a roaming mobility service provider in response to the reservation request; providing traveler information based on the traveler profile to a transportation operator so that the traveler can use mobility services of the roaming mobility service provider; The traveler profile is provided by a home mobility service provider. method. (7) A communications network node comprising a circuit, the circuit comprising: providing credentials for the traveler based on a decentralized identifier for the traveler; configured to transmit said credentials to a user equipment to enable the traveler to use a mobility service of a roaming mobility service provider; The credentials are generated in a distributed database based on a request to the distributed database, the request being issued in the communication network node. Communication network node. (8) the circuitry is further configured to provide a decentralized identifier electronic wallet; (7) A communication network node according to (7). (9) the credentials are represented in the decentralized identity electronic wallet; (8) A communication network node according to (8). (10) A method for controlling a communications network node, comprising: providing credentials for the traveler based on the traveler's decentralized identifier; and transmitting said credentials to a user equipment so that the traveler can use a mobility service of the roaming mobility service provider; The credentials are generated in a distributed database based on a request to the distributed database, the request being issued in the communication network node. method. (11) A user equipment having a circuit, the circuit comprising: receiving at least one credential of a plurality of credentials in response to a carrier request to the user equipment; configured to transmit the at least one credential to the transportation provider to enable the traveler to use mobility services of the transportation provider; The transportation operator's request is based on a roaming mobility service provider's reservation request for the traveler to the transportation operator. User equipment. (12) The credentials are verified by the transportation carrier to allow the traveler to use the transportation carrier's mobility services. (11) A user device as described in (11). (13) The verification is based on a query to a centralized database. (12) A user device as described in (12). (14) The centralized database is assigned to at least one issuer of the at least one credential. (13) A user device as described in (13). (15) The verification is based on a distributed ledger query. A user device according to any one of (11) to (14). (16) The distributed ledger is based on a blockchain. (15) A user device as described in (15). (17) The verification of the at least one credential is based on a hash function. A user device according to (15) or (16). (18) The verification of the at least one credential is further based on a Merkle tree. (17) A user device as described in (17). (19) An electronic network node comprising a circuit, the circuit comprising: configured to validate at least one credential of the traveler in response to a request by the traveler to use a mobility service of a roaming mobility service provider; This validation is based on distributed ledger queries. Electronic network node. (20) The distributed ledger is based on blockchain. (19) An electronic network node according to (19). (21) The verification of the at least one credential is based on a hash function. An electronic network node according to (19) or (20). (22) The verification of the at least one credential is further based on a Merkle tree. (21) An electronic network node according to (21). (23) A method for controlling an electronic network node, comprising: verifying at least one credential of the traveler in response to a request from the traveler to use a mobility service of a roaming mobility service provider; The verifying step is based on a query of a distributed ledger. method. (24) The distributed ledger is based on blockchain. (23) An electronic network node according to (23). (25) The verification of the at least one credential is based on a hash function. An electronic network node according to (23) or (24). (26) The verification of the at least one credential is further based on a Merkle tree. (25) An electronic network node according to (25). (27) An electronic network node comprising a circuit, the circuit comprising: selecting at least one credential of the plurality of credentials in response to a request from the user equipment; and configured to transmit the at least one credential to the user equipment to enable the traveler to use a mobility service of a transportation provider. Electronic network node. (28) A method for controlling an electronic network node, comprising: selecting at least one credential of the plurality of credentials in response to a request from the user equipment; and transmitting the at least one credential to the user equipment so that the traveler can use a mobility service of a transportation provider. method.

Claims

1. A communications network for providing a distributed ledger, the network network including a plurality of network nodes, the network nodes comprising: providing a traveler profile of the traveler to the roaming mobility service provider in response to a reservation request from a terminal device of the traveler having a service contract with the home mobility service provider; requesting a traveler profile of the traveler from the home mobility service provider and receiving the traveler profile of the traveler; and circuitry configured to provide traveler information based on the traveler profile to a transportation carrier so that the traveler can use mobility services of the roaming mobility service provider. Communications network.

2. The distributed ledger is based on blockchain The communications network of claim 1.

3. The traveler profile includes personal data. The communications network of claim 1.

4. The traveler information indicates the personal data.

4. The communications network of claim 3.

5. The traveler information includes at least one of the traveler's name, date of birth, gender, and passport information. The communications network of claim 1.

6. A method of controlling a communications network for providing a distributed ledger, the network nodes including a plurality of network nodes, the network nodes having circuitry, the circuitry comprising: providing a traveler profile of the traveler to the roaming mobility service provider in response to a reservation request from a terminal device of the traveler having a service contract with the home mobility service provider; requesting a traveler profile of the traveler from the home mobility service provider and receiving the traveler profile of the traveler; providing traveler information based on the traveler profile to a transportation carrier so that the traveler can use the mobility services of the roaming mobility service provider; method.

Images