DE102019135633A1 - DECENTRALIZED CLOUD-BASED AUTHENTICATION FOR VEHICLES AND ASSOCIATED TRANSACTIONS - Google Patents

Abstract

The disclosure provides decentralized cloud-based authentication for vehicles and associated transactions. Systems, methods and computer-readable media for decentralized authentication for autonomous vehicles and associated transactions are disclosed. An exemplary system includes a secure distributed network of servers, including a biometric server configured to authenticate a user using biometric data and to generate a biometric server authentication token when the user is authenticated, a transaction server configured to perform the transaction for the user upon receipt of the biometric server authentication token, the transaction server further configured to generate a transaction server authentication token when the transaction is approved and a mobility service server configured to use both the biometric server authentication token and receive the transaction server authentication token and provide access to the mobility service.

Description

CROSS REFERENCE TO RELATED APPLICATION (DE)

This application is a partial continuation of the one submitted on July 20, 2018 US application with serial number 16 / 041,276 entitled “DECENTRALIZED CLOUD-BASED AUTHENTICATION FOR AUTONOMOUS VEHICLES”, which is hereby incorporated by reference in its entirety, including all references and appendices mentioned therein for all purposes.

TECHNICAL AREA

The present disclosure relates to systems, methods, and computer-readable media for decentralized cloud-based authentication of vehicles and for facilitating transactions in a secure and distributed manner.

GENERAL PRIOR ART

Users may be interested in using autonomous vehicles for transportation purposes. However, since a human driver cannot be in an autonomous vehicle, authentication of a driver's identity can be important to ensure that the user is in the correct autonomous vehicle. Personal data can be used to authenticate a driver. However, this information can be vulnerable to hacking and / or other cyber security risks.

With the increasing use of mobility service platforms, there must also be a seamless way of handling transactions. For example, it may be desirable for a customer to watch a movie while driving in an autonomous vehicle. While there are traditional methods of performing transactions, such as For example, asking the customer to provide credit card information and filling out a form for each transaction prevents the cumbersome process of these processes from taking advantage of some offers.

A cloud-based platform that supports both personal data storage and biometric authentication would be a direct, device-free solution. The challenge with these platforms is that the risk of data theft is significant. If a hacker gets access to the backend services, he not only knows who the customer is, but also knows his credit card and biometric data.

SUMMARY OF THE INVENTION

Systems, methods and computer-readable media for decentralized authentication for autonomous vehicles and associated transactions are disclosed. An exemplary system includes a secure distributed network of servers, including a biometric server configured to authenticate a user using biometric data and to generate a biometric server authentication token when the user is authenticated, a transaction server configured to perform the transaction for the user upon receipt of the biometric server authentication token, the transaction server further configured to generate a transaction server authentication token when the transaction is approved and a mobility service server configured to use both the biometric server authentication token and receive the transaction server authentication token and provide access to the mobility service.

Figure list

• 1 10 is a schematic illustration of an example implementation of decentralized cloud-based authentication for autonomous vehicles according to one or more embodiments of the disclosure.
• 2nd FIG. 4 is a schematic illustration of an example method for decentralized cloud-based authentication for autonomous vehicles according to one or more embodiments of the disclosure.
• 3rd includes schematic illustrations of example user interfaces for decentralized cloud-based authentication for autonomous vehicles according to one or more embodiments of the disclosure.
• 4th 13 is a schematic illustration of an exemplary autonomous vehicle according to one or more embodiments of the disclosure.
• 5 14 is a schematic illustration of an example server architecture according to one or more embodiments of the disclosure.
• 6 10 is a schematic illustration of an example implementation of decentralized cloud-based authentication for autonomous vehicles that also provide secure transactions, according to one or more embodiments of the disclosure.
• 7 FIG. 10 is a flow diagram of an example method of registering a user in accordance with the present disclosure.
• 8th FIG. 10 is a flow diagram of an example method for authorizing and delivering a mobility service using the distributed architecture 6 .
• 9 FIG. 4 is a flow diagram of an example method of providing access to a mobility service in accordance with the present disclosure.

DETAILED DESCRIPTION

Embodiments of the present disclosure are described herein. However, it is to be understood that the disclosed embodiments are merely examples and other embodiments may take various and alternative forms. The figures are not necessarily to scale; some features could be enlarged or reduced to show details of specific components. Therefore, the concrete structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis to teach those skilled in the art to use various forms of the disclosure in a variety of ways. Those of ordinary skill in the art understand that various features illustrated and described with reference to any of the figures may be combined with features illustrated in one or more other figures to produce embodiments that are not expressly illustrated or described. The combinations of illustrated features provide representative embodiments for certain applications. However, various combinations and modifications of the features consistent with the teachings of this disclosure may be desirable for specific applications or implementations.

1 is a schematic illustration of an exemplary implementation 100 decentralized cloud-based authentication for autonomous vehicle according to one or more embodiments of the disclosure. Although the example is from 1 illustrates a system with two discrete cloud-based servers, other embodiments may include a different number of servers or server systems. An example of a server architecture is related to at least 5 described.

While some of the embodiments disclosed herein relate to autonomous vehicles, it should be understood that the system and methods of the present disclosure are not so limited. That is, the systems and methods disclosed herein can be used in other modes of transportation, such as airplanes, trains, or other means of transportation with entertainment / infotainment systems that offer services such as movies, music, or other entertainment.

Driver authentication can be important for autonomous vehicles because a human operator may not be available to verify a driver's identity. This can result in a driver getting into the wrong autonomous vehicle, driving a driver to a wrong destination, and so on. Some methods of checking the driver use biometric features such as facial features, fingerprints, gait analysis and the like. However, this data may be desired by hackers and other cyber security threats. Accordingly, it may be desirable to protect information used to verify the driver's identity.

Embodiments of the disclosure provide systems and methods for managing biometric data to reduce or eliminate the risk of unauthorized access to the biometric data that can be used for driver authentication. Certain embodiments use a variety of discrete cloud-based servers to separate the storage of biometric and personal information from drivers or users. For example, a first cloud-based server and a separate, discrete second cloud-based server can be used to store biometric data and personal information separately. Embodiments of the disclosure thus provide a solution for authenticating the driver's identity without forcing a user to look at each individual device (e.g., a reader, scanner, or other device for collecting biometric data that is a device of an autonomous vehicle or may be a user device) used by the user to authenticate them. For example, if authentication determinations were made locally to devices associated with a particular vehicle, users would have to create an account on each device they want to use for authentication. During the account creation process, users may need to create a basic biometric template for the user that is stored on a local device and can be used for subsequent authentication, as discussed in detail below. The registration is related to 3rd described in detail and can be a process in which a user enters a Profile using a biometric template that can be used for subsequent biometric authentication. Registration can be the initial account creation process. Embodiments of the disclosure include a decentralized biometric authentication system that can be adapted to any desired need.

Embodiments of the disclosure include systems and methods, as well as autonomous vehicles, that include functions, including authentication of drivers without human input. Some embodiments may use more than one cloud-based server or server system (e.g., a group of servers) to store data and / or authenticate a driver. Accordingly, in the event of a breach, embodiments of the disclosure can automatically verify the user's identity without providing access to both driver's personal information (e.g., account information) and biometric data.

As an overview, embodiments of the disclosure may include an autonomous vehicle 120 , a first server 160 and a second server 170 include. A user may request autonomous vehicle travel using a mobile application, which in one example runs on a user device. The request can be sent to the second server 170 be sent. In some cases, the request may include a user account identifier that is linked to a user account from which the request was made. The second server 170 can receive the request and determine the user account identifier. The second server 170 may be in communication with one or more local or remote data stores that provide user account identifiers in association with authentication identifiers (which may be an anonymous identifier that lack personally identifiable information associated with a user and / or user account) Save user accounts. The second server 170 may query the one or more databases to determine the authentication identifier associated with the user account identifier from the request. The second server 170 can then respond to a message from the first server 160 wait, indicating that a biometric challenge has been met. The message from the first server 160 can contain an authentication identifier. If the authentication ID provided by the second server 170 from the first server 160 is received with that of the second server 170 specific authentication identifier matches (using the user account identifier), the second server 170 send an access token to an autonomous vehicle or to a user device to grant the user access to the autonomous vehicle. The process by which the first server 160 determines whether a biometric challenge is met is described below.

To authenticate a driver based on a biometric challenge, a user device (e.g. smartphone, smartwatch, etc.) or one of the autonomous vehicle 120 associated device, such as a camera, a fingerprint scanner, a microphone, etc., can be used to capture one or more biometric features of a user familiar with the autonomous vehicle 120 approaches or is there. The autonomous vehicle 120 or the user device may include one or more computer processors or controllers that process the input of the biometric feature and determine a set of extracted feature data that may represent symmetry of the user's face, facial depth features, skin tone analysis, fingerprint features, etc. The extracted feature data can be sent to the first server 160 sent to match against a database of existing biometric templates for users. The biometric templates can contain extracted feature data for users who have created user accounts for biometric authentication. The first server 160 can determine a biometric template that matches the extracted feature data from the autonomous vehicle 120 were received. The identified biometric template can be linked to an authentication identifier that is unique to the user. The authentication identifier can be obtained from the first server 160 in a message to the second server 170 be sent. As discussed above, the second server 170 determine that the authentication identifiers match and grant access to the autonomous vehicle by sending an access token to the user's device or the autonomous vehicle.

In 1 a user can approach and / or get into an autonomous vehicle. The user can make a number of user inputs 110 to initiate a verification process. For example, the user can access 112 request (e.g. via a door handle or an input pad on a vehicle, via a mobile application interface, via the vehicle's detection of the mobile device by wireless communication, via a verification device in the vehicle, etc.). In some embodiments, access can be by physically contacting or touching an autonomous vehicle 120 be requested, while in other embodiments access by voice commands, detection of a User device can be requested using wireless communication such as Bluetooth or near field communication or other non-physical user input.

To access the autonomous vehicle 120 the user can get raw biometric data 114 which may be an image (e.g., a selfie, etc.), a video of the user walking or making a specific face, audio recordings of their language, a fingerprint image or sensor output, and so on. The raw biometric data 114 can be captured by a component of an autonomous vehicle or can be captured by the user's device once the user is near a particular autonomous vehicle. For example, the user can take a selfie with the user's smartphone or a vision system on the autonomous vehicle can be used to take a selfie of the user to authenticate the user's identity. Likewise, an acoustic message can be used in another form of biometric data and can be used to authenticate the driver based at least in part on features of the voice data extracted from the acoustic message. In some embodiments, the user may be able to use their own biometric data entry device, such as in cases where the user's device is connected to the autonomous vehicle using a wireless connection such as Bluetooth or NFC. An autonomous vehicle 120 can the user input 110 receive. The autonomous vehicle 120 can be a biometric input system 130 , a driver processing component 140 and a telematics control unit 150 include. The biometric input system 130 can the user input 110 received and can one or more activation components 132 to activate the autonomous vehicle 120 include if (e.g., during or after, etc.) based on the requested access 112 , such as by the user who is the autonomous vehicle 120 approaches or touches this. Activating the vehicle may include starting an engine, turning on a display, presenting one or more user interfaces, and the like. In some cases, the vehicle may not need to be activated and remains in an active state.

The biometric input system 130 (eg cameras, infrared sensors, face recognition systems, fingerprint sensors, microphones, etc.) can have one or more feature extraction components 134 contain the biometric feature data or information from the user input 110 received raw biometric data 114 extract. So the feature extraction component 134 extract facial symmetry features, depth features, and the like from an image or video of the user, fingerprint data from a user's fingerprint, gait data from a gait analysis of a video of the user approaching the vehicle, gestures, spectral component analysis of speech, and / or other feature data. These features can also be generated by using a folding depth network and / or a neural network, with features of a higher order being able to be abstracted from raw data sources such as video or audio recordings.

The extracted feature data can be used by the driver processing component 140 are provided with the biometric input system 130 and the telematics control unit 150 can be in communication. Extracted feature data may include numerical representations of a user's face structure, unique features of a user's fingerprint, user's speech patterns, and the like. The driver processing component 140 can the feature data of the telematics control unit 150 for a biometric challenge 152 provide or work in conjunction with this. The driver processing component 140 can from the telematics control unit 150 have separate or thus common computer processors. In some embodiments, the driver processing component 140 a separate computer system in communication with the telematics control unit 150 be. The telematics control unit 150 can be local to the vehicle 120 available computer system (and may be in some embodiments of the controller 406 out 4th correspond).

The biometric challenge 152 can be used to collect biometric data from the first cloud-based server 160 can be used to authenticate the user, ie to determine whether the user is a particular user, such as an expected driver. An expected driver may be a driver associated with an account that ordered the autonomous vehicle, or a driver identified as a designated passenger during the autonomous vehicle ordering process (e.g., a son may use an autonomous vehicle for his Order mother etc.). To the biometric challenge 152 For example, the extracted feature data may need to perform a threshold similarity comparison with stored biometric data. For example, extracted facial feature data may require a percentage match, for example a 95% match (or any other suitable threshold similarity) that must be stored with facial feature data for the specific user (as by the first cloud-based server 160 determined as discussed below). Matches can be made with a remote computer system in communication with the vehicle 120 be determined, such as a first cloud-based server 160 as described below. The telematics control unit 150 can be an optional driver verification component 154 involve that in addition to the biometric challenge 152 can be executed. The driver verification component 154 may, in one example, prompt a user for a password, passcode, or other authentication credential for additional verification of user identity. The driver verification component 154 can extract extracted feature data from a user's biometric data to the driver processing component 140 communicate. In some embodiments, the driver verification component 154 run to extracted feature data to the first cloud-based server 160 to send. So the driver verification component 154 the extracted feature data, for example, to the first cloud-based server 160 send and from the second cloud-based server 170 Receive back data indicating a positive or negative verification result (which may take the form of an access token).

The telematics control unit 150 can be local to the vehicle 120 available computer system (and may be, for example, the controller in some embodiments 406 in 4th correspond). The telematics control unit 150 can with the first cloud-based server or server system 160 communicate, which can be a biometric cloud system. The first cloud-based server 160 may be configured to verify driver identity based on extracted feature data from the autonomous vehicle 120 be received. So the first cloud-based server 160 for example an authentication component 166 which contain the extracted feature data from the autonomous vehicle 120 receives and the extracted feature data and one or more biometric templates (which may be stored basic feature data for a particular user's biometric features that were acquired during a registration process, such as in relation to FIG 3rd described) 162 as inputs to the authentication component 166 can use. Biometric templates 162 may be templates or profiles that contain extracted basic biometric feature data for users who have registered for a biometric authentication service, an example of which is shown in FIG 3rd is described.

The authentication component 166 can extract the extracted feature data using one or more of the biometric templates 162 compare and, when determining a suitable match, the associated authentication identifier 164 determine. For example, extracted facial feature data may need to be a percentage match, for example a 95% match (or any other suitable threshold similarity), to stored facial feature data for the particular user. The authentication identifier 164 can be stored in a local or remote database in association with appropriate biometric templates. The authentication component 166 can be a neural detection network 168 use to improve the performance of authentication tasks over time. If matches from the first cloud-based server 160 For example, subsequent matches can be found in a shorter time by taking into account the difference between the extracted feature data for the same user (e.g. a selfie at a different angle, etc.). Any suitable machine learning algorithms can be used.

The authentication identifier 164 may not contain any personally identifiable information in some embodiments. Rather, the authentication identifier 164 can be a randomly generated, unique sequence of characters or images and can be created using a specific biometric template 162 be linked. The biometric template is created for the user during a registration process that enables the user to collect basic biometric feature data that is then used for subsequent authentication to the user. For example, the user can take 5 different selfies from different angles during registration. Features can be extracted from each of the 5 selfies and a subsequent user authentication can be included in the biometric template for the user.

The telematics control unit 150 can with the first cloud-based server 160 and a second cloud-based server or server system 170 (which can be a cloud system of an autonomous vehicle) communicate. The first cloud-based server 160 and the second cloud-based server 170 can communicate with each other to share authentication IDs. The second cloud-based server 170 can be configured to use the authentication identifier of a user (e.g. by finding an authentication identifier associated with a user account in a database etc.) and / or to grant access to an autonomous vehicle (e.g. by generating an access token which acts as a digital key for unlocking an autonomous vehicle and / or to initiate a journey, etc.). The second cloud-based server 170 can access one or more local or remote databases that hold personal information 172 in association with the authentication identifiers 174 are saved.

If a user requests a trip with an autonomous vehicle, the request can be sent to the second cloud-based server, for example 170 be sent. The request may include a user account identifier, as discussed above. The second cloud-based server 170 may contain one or more personal information that may be associated with the request (e.g. user account ID, email address, device ID (e.g. MAC address, serial number, etc.), home address, phone number, etc.) Entries on one or more driving data components 176 use (the driver verification module 526 out 5 can correspond). The driving data component 176 may be a software component configured to access and / or query the one or more databases in which the personal information 172 and / or the authentication identifiers 174 are stored in association with each other to determine the authentication identifier associated with a particular personal information. An exemplary process for creating an authentication identifier for a user account is related to 3rd described. The driver data component 176 can communicate with a driver planning service or component (s) 178 of the autonomous vehicle that can receive and / or process requests for autonomous vehicles for users (e.g., users can use a mobile application to plan or request trips, etc.). The driver data component 176 May be the data (e.g. the user account identifier) provided by the scheduling component 178 of the autonomous vehicle (which receives the trip request data from the user device, which may include the user account identifier), to determine an expected driver and / or other details for an expected driver of an autonomous vehicle. The expected driver may be a driver determined during a drive request using the user device when a user requests a drive.

If the authentication ID provided by the second cloud-based server 170 was determined (using the user account identifier associated with a trip request) with that by the second cloud-based server 170 from the first cloud-based server 160 received authentication identifier (as determined using the extracted feature data), the driver can be authenticated and can give the autonomous vehicle or the user device an access token from the second cloud-based server 170 be sent to access the autonomous vehicle and / or initiate a trip when the user is already in the vehicle.

A method of verifying driver identity using a decentralized system, as described, for example, in 1 is shown with reference to 2nd explained in detail. For example, the process may include receiving a user request to access an autonomous vehicle, extracting biometric features from the user's raw biometric data, and then using separate and discrete cloud-based systems to process subsets of all of the personal information for review.

Embodiments of the disclosure can minimize the amount of useful information that can be accessed without authorization by storing incomplete records in different areas. In this way, a hacker or other unauthorized person should have access to the first server or the first server system, which stores the biometric templates and / or biometric data, to the second server or the second server system, which stores the driver's personal data and then know how the records are linked.

Certain embodiments may use raw biometric data that is publicly available at low resolution. For example, 3D face recognition offers security, but also information that is likely to be readily available on the Internet at low resolution. Low-resolution images would not be sufficient to authenticate in the system, but would attempt to hack into the biometric authentication server to deprive them of the incentive (compared to fingerprint recognition or iris properties).

Accordingly, the embodiments of the disclosure include a decentralized, cloud-based biometric authentication system that is biometric and personal Separates data for security reasons. One cloud service can be used to match a biometry with a registered user account or ID, and a second, separate cloud service can retrieve the personal information of the user account or authentication ID from one or more databases and provides access to that autonomous vehicle after determining that the authentication identifier corresponds to personal information for an expected driver. For example, a passenger can request a ride on the autonomous vehicle using a user account on an application running on a mobile device. The second cloud-based server can receive the request (e.g. via the driver planning component 178 of the autonomous vehicle, etc.) and can identify a specific autonomous vehicle for the user. When the user reaches an autonomous vehicle, the autonomous vehicle can wirelessly communicate extracted biometric feature data to the first cloud-based server. The first cloud-based server can determine an authentication identifier associated with a biometric template that matches the extracted biometric feature data (received from the autonomous vehicle). The first cloud-based server can then send the authentication identifier to the second cloud-based server (shown as an authentication identifier 174 in 1 ). The second cloud-based server may determine an associated user account or other personal information associated with the authentication identifier received from the first cloud-based server. If the associated user account matches the user account (e.g., the expected driver, etc.) that requested the autonomous vehicle ride, the second cloud-based server may send an access token to the autonomous vehicle. If the associated user account does not match the user account and / or the expected driver, the second cloud-based server can send a wrong vehicle token to the autonomous vehicle and / or the user's device. The wrong vehicle token can indicate the location of the correct autonomous vehicle intended for the user.

Additional advantages include increased security through the preprocessing of the biometric data on the scanner and / or autonomous vehicle and the transmission of only the extracted features, so that a hacker cannot be able to intercept the biometric raw data or the image.

2nd is a flowchart of an exemplary process flow 200 for decentralized cloud-based authentication for autonomous vehicles according to one or more embodiments of the disclosure. Some of the blocks out 2nd represent operations from the first cloud-based server 160 , the second cloud-based server 170 and / or the autonomous vehicle 120 out 1 can be carried out. In some embodiments, the operations can be performed in a distributed manner across a variety of computer systems.

block 210 of the process flow 200 may receive first extracted feature data from a user device (e.g., a smartphone, tablet of a component of an autonomous vehicle, a camera, a biometric reader or other device coupled to a vehicle, etc.) by a first cloud-based server that configured to verify user identities using biometric features, wherein the first extracted feature data represents a user's biometric features. For example, the first cloud-based server 160 in 1 receive first extracted feature data from a user device (that on the autonomous vehicle 120 positioned and / or may be an integrated component thereof or may be a mobile device). The extracted feature data may include biometric features such as face depth analysis, facial symmetry analysis, skin tone analysis, and so on. For example, the first extracted feature data can be derived from an image of the user's face, such as a selfie or another image.

block 220 of the process flow 200 may include determining, by the first cloud-based server, that the first extracted feature data matches an authentication identifier. So the first cloud-based server 160 For example, first determine that the extracted feature data match the stored biometric feature data. The stored biometric feature data can be the basic biometric data of the users that were acquired during a registration process, as in FIG 3rd described. The first cloud-based server 160 can compare the extracted feature data with the stored biometric feature data to determine whether there is a match (e.g. whether there is a corresponding data record that is stored in a database accessible to the server, etc.). Then the first cloud -based server 160 determine or identify the authentication identifier associated with the stored biometric feature data (e.g., in a particular biometric template etc.). In one example, the first cloud-based server 160 query a database to identify the authentication identifier associated with a particular biometric template and / or extracted feature data. In some cases, the first cloud-based server 160 determine whether the first extracted feature data match the authentication identifier and / or the stored biometric data of an expected driver. As discussed, the expected driver may be a user account associated with an autonomous vehicle request or another user identified in an autonomous vehicle request. For example, when a user makes a request for an autonomous vehicle through an application on a mobile device, he can designate himself or another user as the driver for the trip. The named driver can be the expected driver. In other embodiments, the expected driver may be unknown. For example, the second cloud-based server can only generate an access token based on the authentication identifier received from the first cloud-based server and the personal information that may not include the named driver's data. The first cloud-based server can use a neural network or other machine learning process that can be performed on a connected computer system to authenticate user identity and / or to improve performance over time.

block 230 of the process flow 200 may include the first cloud-based server sending the authentication identifier to a second cloud-based server configured to generate driver verification or access tokens for accessing autonomous vehicles. For example, after the first cloud-based server has determined the authentication identifier of the user (using the extracted feature data), the first cloud-based server can send the authentication identifier to the second cloud-based server 170 in the example 1 send. The second cloud-based server 170 can be configured to access the autonomous vehicle 120 to grant, which in one example can be done by generating a driver verification token for accessing autonomous vehicles. The driver verification or access token can be sent to the autonomous vehicle to give the user access. The autonomous vehicle can determine that the access token matches an expected key value, which can be a digital key or a string that can act as a key to access the autonomous vehicle. The autonomous vehicle can then unlock one or more doors and / or otherwise grant the user access to the autonomous vehicle and / or start a journey after receiving the access token. In some embodiments, the access token can be sent to a user device, which can then be used by the user to access an autonomous vehicle. The vehicle may receive the access token from the user device and grant the user access to the vehicle and / or begin the journey. The access token can be a digital key that is used by the autonomous vehicle to determine whether to grant access to a user. For example, the access token can be compared to a master key or other value to determine if there is a match, and if so, access can be granted.

block 240 of the process flow 200 may include the second cloud-based server determining a user account associated with the authentication identifier. So the second cloud-based server 170 out 1 for example, determine a user account associated with the authentication identifier. The authentication identifier can be associated with a user account in one or more databases that the second cloud-based server can access. The authentication identifier can be associated with the extracted feature set of the first cloud-based server. In this way, the association between the user account and the extracted feature data for a user can take place indirectly using an authentication identifier which is transmitted between the first cloud-based server and the second cloud-based server. In some embodiments, the authentication identifier is only accessible to the first cloud-based server and the second cloud-based server. For example, the autonomous vehicle 120 never receive and / or access the authentication identifier. In some cases, the user device used to capture a biometric input cannot access or receive the authentication identifier after opening a user account.

block 250 of the process flow 200 may include determining, by the second cloud-based server, that the user account matches an expected user account. So the second cloud-based server 170 out 1 for example, determine that the identified user account matches an expected user account. An expected user account can be a user account from which a trip request or a permission request was received. So the second cloud-based server for example, communicate with a planning system or service of the autonomous vehicle to determine a user account associated with a trip request and / or a user who is named as a driver during a trip request. The information about the specified driver and / or the user account can be used to determine an expected driver of the autonomous vehicle.

If the second cloud-based server determines that the user account does not match an expected user account, the second cloud-based server can send a wrong driver token to the autonomous vehicle. The wrong driver token can indicate that the autonomous vehicle 120 is not intended for the user. In some embodiments, the false driver token may include additional data, such as data related to the location of another autonomous vehicle for the user. For example, the autonomous vehicle intended for the user can be in a taxi queue or a row of autonomous vehicles further ahead or behind. After locating the correct autonomous vehicle, the user can try again to access it.

block 260 of the process flow 200 may include sending a driver verification or access token to an autonomous vehicle through the second cloud-based server for the user to gain access to the autonomous vehicle. So the second cloud-based server 170 out 1 for example a driver verification token for the autonomous vehicle 120 generate and / or send to this so that the user on the autonomous vehicle 120 can access and / or use it. The access token can be generated dynamically and can be from the autonomous vehicle 120 (in particular, the controller of the vehicle) can be used to compare with an expected value to determine whether the access token matches the expected value. If this is the case, the vehicle can unlock itself in order to grant the user access and / or to initiate a journey in accordance with the travel request of the user.

In some embodiments, the method may optionally include the second cloud-based server deleting the authentication identifier and / or the data associated with the trip request after the driver verification token is sent to the autonomous vehicle. For example, the second cloud-based server cannot save the authentication identifier in the long-term storage after the authentication identifier has been received by the first cloud-based server. In some cases, data associated with a trip request, such as user account IDs, can be automatically deleted after an access token is sent from the second cloud-based server.

In some embodiments, during a registration process and / or an authentication process, the first cloud-based server may send the authentication identifier to the user device for storage in RAM memory. The user device can therefore delete the authentication identifier in due course. In some embodiments, the user device may send the authentication identifier to the second cloud-based server before deletion.

In one example, biometric authentication can be initiated by the user activating the autonomous vehicle and / or the biometric reader and following the recognition process. Activation can be triggered by touching the door handle, pairing the vehicle with the driver's phone, and determining that a person is within a short distance of a door by the environmental sensors (such as LIDAR) of a parked vehicle.

The autonomous vehicle and / or the biometric reading device can break down the scanned data into the required model feature inputs. Standard features of the face include detecting edges to associate face shape, tracking facial proportions (e.g., relative distance between eyes and length of nose, etc.), infrared blood vessel patterns, and / or changes in 3D depth detected by bifocal lenses or ultrasound sensors (e.g. relative ratio of how far the cheeks protrude, to the eye socket, etc.). These extracted features can be encrypted and sent to the first cloud-based server (e.g. biometric server) as an authentication challenge.

The first cloud-based server can compare the received encrypted features with one or more template archives. If no match is found, the first cloud-based server can communicate with the vehicle to request a new biometric scan. In some cases, the autonomous vehicle 120 and / or the user device includes an indicator for providing feedback, such as the blinking of a red LED. This process could be repeated iteratively, (i) until the driver is authenticated, (ii) up to a limited waiting time (to get current drivers in the Vehicle) and / or (iii) up to a limited number of rejections. A decision-making logic on the autonomous vehicle 120 can be implemented in cases where no valid driver is found. In cases where the first cloud-based server finds a match, the first cloud-based server can transmit the associated authentication token to the second cloud-based server. The second cloud-based server can retrieve the driver's personal information associated with the authentication token. If the authentication token matches the expected driver and / or the expected user account, the second cloud-based server can send a driver verification token to the autonomous vehicle to grant access and continue / start a journey. If the authentication token does not match the expected driver and / or user account, the second cloud-based server sends a wrong driver token to the vehicle, which informs them that it is someone else. If desired, the vehicle can send a greeting and / or other information informing the user that he has another vehicle and where it is via image or audio systems of the autonomous vehicle and / or the user device.

In some embodiments, the autonomous vehicle can never receive the authentication identifier. The authentication identifier can only be exchanged between the biometric authentication server (e.g. the first cloud-based server) and the second cloud-based server. In such embodiments, there should not be an individual computer system in which the full data set of raw biometric data, authentication identifier and personal information exists.

3rd Figure 3 is a schematic illustration of exemplary user interfaces 300 for decentralized cloud-based authentication for autonomous vehicles according to one or more embodiments of the disclosure.

At a first user interface 310 For example, a user device can be used to collect raw biometric data for user input. For example, the user device can be the user's own mobile device or a device on an autonomous vehicle. The biometric data can be an image, such as an image of the user's face. The captured biometric data (or extracted features from the biometric data, such as a numerical representation of the unique biometric features of the user) can be sent to the first cloud-based server 160 in 1 sent and saved as part of a biometric template for the user. The biometric template can be stored in association with a unique authentication identifier for the user.

Biometric templates 162 in 1 may include extracted basic biometric characteristic data for users who have registered for the biometric authentication service.

At a second user interface 320 may indicate a confirmation message that the user is authenticated and may indicate that the user can access a particular autonomous vehicle.

3rd contains an example process flow for registering for a biometric authentication service for autonomous vehicles.

block 330 may include sending a first request for an authentication identifier by a user device that includes one or more computer processors coupled to at least one memory to a first cloud-based server. In this example, the first cloud-based server can be the second cloud-based server 170 out 1 be. The authentication identifier can be associated with a first user account for a user of an autonomous vehicle. The request for the authentication identifier can optionally include initially acquired extracted feature data that can be used for the subsequent driver authentication.

block 340 may include determining, by the user device, extracted basic feature data representing biometric features of the user. For example, the user device may take a series of images of a user's face to determine basic or initial extracted feature data that can be used for subsequent authentication to the driver.

block 350 may include sending the authentication identifier and extracted basic feature data in an encrypted format by the user device to a second cloud-based server. The second cloud-based server can be configured to use the extracted basic feature data for biometric authentication. In this example, the second cloud-based server can be the first cloud-based server 160 out 1 be. The user device can receive the authentication identifier from the first cloud-based server (which is optional in response to the first request at block 330 can be received) and / or can generate the authentication identifier and can send the authentication identifier and optionally the extracted basic feature data to the second cloud-based server.

block 360 may include deleting the authentication identifier by the user device. For example, the authentication identifier can be stored in RAM memory and deleted from the user device at a given time or actively as soon as the authentication identifier has been sent to the second cloud-based server. In some embodiments, the authentication identifier may be received by the first cloud-based server and stored in RAM.

In some cases, the user device and / or the autonomous vehicle may determine an image of the user, determine first extracted feature data based on the image, and send a biometric authentication request to the second cloud-based server. The biometric authentication request can include the first extracted feature data.

In some embodiments, the first cloud-based server, the second cloud-based server, and the user device do not send the authentication identifier to the autonomous vehicle. This is done in order to avoid that the biometric data, personal information and the authentication identifier are available on the autonomous vehicle.

In an example process flow for registration, registration can be initiated when a user creates an account in a mobile application using a device. The device can connect to a driver verification server (such as the second cloud-based server 170 in 1 ) to create a personal profile that can include a user's desired personal information and the generation of an authentication identifier. The driver verification server can generate a random, unique authentication identifier for the user and associate this with the personal information. This authentication identifier can be sent to the user's device for temporary storage in RAM. This is because the authentication identifier can be automatically deleted from the user's device after the registration is completed.

Once the user creates an account, the device can prompt the user to register their biometric data. The device can be used in relation to 3rd Perform feature extraction discussed and ask for a secondary "selfie" or other input to verify that the model can recognize it. This "selfie" registration process can be repeated until the recognition test is successful. After a quality reference record is obtained (e.g., the extracted base feature data), the device sends a new account request to the biometric authentication server (such as the first cloud-based server) 160 in 1 ), providing an encrypted version of the extracted features and the authentication identifier. The authentication identifier is then deleted from the device memory. The biometric authentication server receives the new account request and creates a user account for the user, in which the authentication identifier is associated with the extracted features in the form of a biometric template.

With reference to 4th includes an exemplary autonomous vehicle 400 (that of the autonomous vehicle 110 out 1 may correspond to) an engine 402 (such as an internal combustion engine and / or an electric motor), the torque for driven wheels 404 provides that drive the vehicle forward or backward. As soon as an access token is received by an autonomous vehicle from the second cloud-based server, the autonomous vehicle can unlock and / or start a journey by driving to a destination specified by the user during the journey request input.

The operation of the autonomous vehicle, which includes drive, steering, braking, navigation and the like, can be controlled by a vehicle 406 be controlled autonomously. For example, the vehicle controller 406 configured to provide feedback from one or more sensors (e.g. the sensor system 434 etc.) and other vehicle components to determine road conditions, vehicle positioning and so on. The vehicle control 406 can also record data from the speed monitoring and yaw rate sensor, as well as the tires, brakes, electric motor and other vehicle components. The vehicle control 406 may use the feedback and route / map data of the route to determine actions to be performed by the autonomous vehicle, which may include operations related to the engine, steering, braking, and so on. Control of the various vehicle systems can be implemented using any suitable mechanical means, such as servo motors, robotic arms (e.g., to control steering wheel operation, accelerator pedal, brake pedal, etc.) and so on. The control 406 may be configured to process the route data for a neighborhood tour, and may be configured to interact with the user through the in-car user interface devices and / or by communicating with the user's user device.

The vehicle control 406 may include one or more computer processors coupled to at least one memory. The vehicle 400 can be a braking system 408 include the brake discs 410 and calipers 412 having. The vehicle 400 can be a steering system 414 include. The steering system 414 can be a steering wheel 416 include, with a steering shaft 418 the steering wheel with a rack 420 (or a steering gear) connects. The front and / or rear wheels 404 can over the axis 422 with the rack 420 be connected. A steering sensor 424 can near the steering shaft 418 be arranged to measure a steering angle. The vehicle 400 also includes a speed sensor 426 who on the wheels 404 or can be arranged in the transmission. The speed sensor 426 is configured to send a signal to the controller 406 output that indicates the speed of the vehicle. A yaw rate sensor 428 is in communication with the controller 406 and is configured to output a signal representing the yaw rate of the vehicle 400 indicates.

The vehicle 400 includes a cabin that has a display 430 in electronic communication with the controller 406 having. The ad 430 can be a touchscreen that displays information to the passengers of the vehicle and / or serves as input, such as whether the driver is authenticated or not. It will be understood by those of ordinary skill in the art that many different display and input devices are available and that the present disclosure is not limited to a specific display. An audio system 432 may be located within the cabin and include one or more speakers to provide information and entertainment for the driver and / or passengers. The audio system 432 may also include a microphone for receiving voice input. The vehicle can use a communication system 436 include that is configured to send and / or receive wireless communication over one or more networks. The communication system 436 may be configured to communicate with in-car or off-car devices, such as a user's device, other vehicles, etc.

The vehicle 400 can also include a sensor system for detecting areas outside the vehicle. The vision system can include a variety of different types of sensors and devices, such as cameras, ultrasound sensors, RADAR, LIDAR and / or combinations thereof. The vision system can be used to control the functions of various components with the controller 406 to be in electronic communication. The controller can communicate via a serial bus (e.g. Controller Area Network (CAN)) or via dedicated electrical cables. The controller generally includes any number of microprocessors, ASICs, ICs, memories (e.g. FLASH, ROM, RAM, EPROM and / or EEPROM) and software code to work together to perform a series of operations. The control also contains predetermined data or “lookup tables”, which are based on calculations and test data and are stored in the memory. The controller can communicate with other vehicle systems and controls via one or more wired or wireless vehicle connections using standard bus protocols (e.g. CAN and LIN). As used herein, reference to “a controller” refers to one or more controllers and / or one or more computer processors. The control 406 can receive signals from the vision system 434 received and may include memory that contains machine readable instructions for processing the data from the vision system. The control 406 can be programmed to display instructions at least 430 , the audio system 432 , the steering system 424 , the braking system 408 and / or the engine 402 issue to the vehicle 400 to operate autonomously.

5 Fig. 3 is a schematic illustration of an example server architecture for one or more servers 500 according to one or more embodiments of the disclosure. The one in the example 5 illustrated server 500 can be one or both of the servers 160 , 170 correspond to that in 1 illustrated and in relation to the 2-4 are discussed. In some embodiments, the server 500 however one, but not both, of a driver verification component (s) 526 or an access token component (s) 528 include. If the server 500 for example the first cloud-based server 160 the server can 500 the driver verification component (s) 526 and not the access token component (s) 528 involve while if the server 500 the second cloud-based server 170 is the server 500 the access token component (s) 528 and not the driver verification component (s) 526 can include. Some or all of the individual components may be optional and / or different in different embodiments. In some embodiments, at least one of the in 1 described and / or in 5 illustrated server are located on an autonomous vehicle.

The server 500 can with the autonomous vehicle 540 and one or more user devices 550 to be in communication. The autonomous vehicle 540 can be in communication with the user device 550 stand.

The server 500 , the autonomous vehicle 540 and / or the user device 550 can be configured over one or more networks 542 to communicate. The autonomous vehicle 540 can also use a connection protocol such as Bluetooth or near field communication in wireless communication 544 with the user device 550 stand. Such a network or networks 542 can include, among other things, any one or more different types of communication networks, such as cable networks, public networks (e.g. the Internet), private networks (e.g. frame relay networks), wireless networks, cellular networks, Telephone networks (e.g., a public switched telephone network) or any other suitable private or public packet switched or circuit switched network. Furthermore, such network (s) can have any suitable communication range associated therewith and, for example, global networks (e.g. the Internet), regional networks (MANs), wide area networks (WANs), local networks ( LANs) or personal networks (PANs). In addition, such network (s) may include communications links and associated networking devices (e.g., data link switches, routers, etc.) for transmitting network traffic over any suitable type of medium, including coaxial cables, cables with twisted wire pairs (e.g., copper wire with twisted wire pairs), optical fiber, a hybrid fiber coaxial medium (HFC medium), a microwave medium, a high frequency communication medium, a satellite communication medium or any combination, is not limited to this.

In an illustrative configuration, the server can 500 one or more processors (processor (s)) 502 , one or more storage devices 504 (here also as memory 504 designated), one or more input / output interface (s) (I / O interface (s)) 506 , one or more network interface (s) 508 , one or more sensor (s) or one or more sensor interface (s) 510 , one or more transceivers 512 , one or more optional display components 514 , one or more optional / camera (s) / microphone (s) 516 and data storage 520 include. The server 500 can also one or more bus (s) 518 include the various components of the server 500 couple functionally. The server 500 can also have one or more antennas 530 include, among other things, a cellular antenna for transmitting or receiving signals to / from a cellular network infrastructure, an antenna for transmitting or receiving Wi-Fi signals to / from an access point (AP), an antenna for a global navigation satellite system ( GNSS) for receiving GNSS signals from a GNSS satellite, a Bluetooth antenna for transmitting or receiving Bluetooth signals, an antenna for near field communication (NFC) for transmitting or receiving NFC signals, and so on can. These various components are described in more detail below.

The bus (s) 518 may include at least one of a system bus, a memory bus, an address bus or a message bus and the exchange of information (e.g. data (including computer executable codes), signaling, etc.) between different components of the server 500 enable. The bus (s) 518 may include, but is not limited to, a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and so on. The bus (s) 518 may be associated with any suitable bus architecture.

The memory 504 of the server 500 may include volatile memory (memory that maintains its state when powered) such as random access memory (RAM) and / or non-volatile memory (memory that maintains its state even when it is not powered) ) such as read only memory (ROM), flash memory, ferroelectric RAM (FRAM) and so on. Persistent data storage may include non-volatile storage as used herein. In certain embodiments, volatile memory can provide faster read / write access than non-volatile memory. However, in certain other embodiments, certain types of non-volatile memory (e.g., FRAM) may allow faster read / write access than certain types of volatile memory.

The data store 520 may include removable storage and / or non-removable storage that includes, but is not limited to, magnetic storage, optical disk storage, and / or tape storage. The data store 520 may provide non-volatile storage of computer-executable instructions and other data.

The data store 520 may store computer-executable code, instructions, or the like stored in memory 504 loaded and by the processor (s) 502 can be executed to the processor (s) 502 to cause various operations to be carried out or initiated. The data store 520 can also store data for use by the processor (s) 502 while executing the computer executable instructions into memory 504 can be copied. In particular, the data store 520 one or more operating systems (O / S) 522 ; one or more database management systems (DBMS) 524; and one or more program module (s), applications, engines, computer-executable codes, scripts or the like, such as one or more driver verification component (s) 526 and / or one or more access token components 528 , to save. Some or all of these component (s) can be (a) subcomponent (s). Any of those as in the data store 520 Components shown stored can contain any combination of software, firmware and / or hardware. The software and / or firmware may include computer-executable code, instructions, or the like, for execution by one or more of the processor (s) 502 in the store 504 can be loaded. Any of the components that are in the data store 520 stored may support functions described with reference to corresponding components identified earlier in this disclosure.

The processor (s) 502 may be configured on the memory 504 access and execute the computer executable instructions loaded therein. For example, the processor (s) 502 configured to execute the computer-executable instructions of the various program modules, applications, engines, or the like of the server 500 perform to cause or facilitate performing various operations according to one or more embodiments of the disclosure. The processor (s) 502 may include any suitable processing unit capable of accepting data as input, processing the input data in accordance with stored computer-executable instructions, and generating output data. The processor (s) 502 may include any type of suitable processing unit.

Referring to the functionality provided by the various in 5 supported program component (s), the driver verification component (s) 526 include computer executable instructions, code, or the like that are responsive to execution by one or more of the processors 502 one or more blocks of the process flow 200 and the process flow 300 and / or perform functions including, among other things, determining extracted feature data, comparing the extracted feature data with biometric templates, sending authentication identifiers to other servers, and the like.

The driver verification component (s) 526 can with the autonomous vehicle 540 , the user device 550 , another server and / or other components are in communication. So the driver verification component (s) 526 for example, receive extracted feature data from the autonomous vehicle, send authentication identifiers to another server and so on.

The access token component (s) 528 may include computer-executable instructions, code, or the like, which may be executed in response to execution by one or more of the processor (s) 502 one or more blocks of the process flow 200 and the process flow 300 and / or perform functions including, among other things, determining user account identifiers, receiving requests, determining authentication identifiers associated with user accounts, generating access tokens and incorrect driver tokens, and the like.

The access token component (s) 528 can with the autonomous vehicle 540 , the user device 550 , another server and / or other components are in communication. So the access token component (s) 528 for example, access token to the autonomous vehicle 540 and / or the user device 550 send, authentication credentials received from other servers and so on.

Referring to other illustrated components than in the data store 520 the O / S 522 from the data store 520 in the store 504 loaded and an interface between other application software running on the server 500 running, and the server's hardware resources 500 provide.

The DBMS 524 can be in memory 504 Loaded and functions for accessing, retrieving, storing and / or editing data stored in the memory 504 and / or data stored in the data store 520 saved, support. The DBMS 524 can be any of a variety of database models (e.g. relational Model, object model, etc.) and support any of a variety of query languages.

Referring to other illustrated components of the server 500 can input / output (I / O) interface (s) 506 the receipt of input information by the server 500 from one or more I / O devices and the output of information from the server 500 to facilitate the one or more I / O devices. The I / O devices can include any of a variety of components, such as a display or display screen having a touch pad or touch screen; an audio output device for generating sounds, such as a speaker; an audio recording device such as a microphone; an image and / or video capture device, such as a camera; a haptic unit; and so on. The I / O interface (s) 506 can also connect to one or more of the antennas 530 include to use a wireless local area network (WLAN) radio (such as Wi-Fi), Bluetooth, ZigBee, and / or a wireless network radio such as a radio capable of communicating with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, ZigBee network, etc. to connect to one or more networks.

The server 500 can also one or more network interface (s) 508 involve through which the server 500 can communicate with any of a variety of other systems, platforms, networks, devices, and so on. The network interface (s) 508 may enable communication with, for example, one or more wireless routers, one or more host servers, one or more web servers, and the like over one or more networks.

The sensor (s) or the sensor interface (s) 510 may include or be capable of interfacing with any type of sensing device such as inertial sensors, force sensors, heat sensors, photocells and so on.

The display component (s) 514 may include one or more display layers, such as LED or LCD layers, touchscreen layers, protective layers, and / or other layers. The optional camera (s) 516 may be any device configured to capture ambient light or images. The optional microphone (s) 516 may be any device configured to receive analog sound inputs or voice data. The microphone (s) 516 may include microphones used to record sounds.

It is understood that the program module (s), applications, computer-executable instructions, code, or the like that are described in 5 than in the data store 520 are stored, are only illustrative and not exhaustive, and that processing described as supported by any particular module may alternatively be distributed across multiple module (s) or performed by another module.

It is also understood that the server 500 may include alternative and / or additional hardware, software or firmware components that go beyond those described or illustrated without departing from the scope of the disclosure.

The user device 550 can one or more computer processor (s) 552 , one or more storage devices 554 and one or more applications, such as an application 556 for autonomous vehicles. Other embodiments may include different components.

The processor (s) 552 may be configured on the memory 554 access and execute the computer executable instructions loaded therein. The processor (s) 552 For example, may be configured to execute the computer-executable instructions of the various program module (s), applications, engines, or the like of the server to cause or facilitate performing various operations according to one or more embodiments of the disclosure. The processor (s) 552 may include any suitable processing unit capable of accepting data as input, processing the input data in accordance with stored computer-executable instructions, and generating output data. The processor (s) 552 may include any type of suitable processing unit.

The memory 554 can be volatile memory (memory that maintains its state when it is powered) such as random access memory (RAM) and / or non-volatile memory (memory that maintains its state even when it is not powered) such as read-only memory (ROM), flash memory, ferroelectric RAM (FRAM) and so on. Persistent data storage may include non-volatile storage as used herein. In certain embodiments volatile memory allow faster read / write access than non-volatile memory. However, in certain other embodiments, certain types of non-volatile memory (e.g., FRAM) may allow faster read / write access than certain types of volatile memory.

Referring to by the user device 550 supported functionality can be the application 556 for autonomous vehicles be a mobile application by the processor 552 is executable and can be used to present options and / or to receive user input of information regarding travel requirements for the autonomous vehicle, travel planning and the like. In addition, the user device 550 with the autonomous vehicle 540 over the network 542 and / or communicate a direct connection, which may be a wireless or wired connection. The user device 550 may include a camera, scanner, bio-reader, or the like to collect a user's biometric data, perform some processing on the biometric data, such as extracting features from captured biometric data, and then extracting those extracted features to one or more removed ones Servers to communicate, such as one or more of the cloud-based servers 160 , 170 . The user device can be accessed through the AV application 556 also facilitate registration, for an example referring to here 3rd is discussed, as well as receiving and processing access tokens and wrong driver tokens.

It is understood that the program module (s), applications, computer-executable instructions, code, or the like that are described in 5 than in the data store 520 are stored, are only illustrative and not exhaustive, and that processing described as supported by any particular module may alternatively be distributed across multiple module (s) or performed by another module.

It is also understood that the server 500 may include alternative and / or additional hardware, software or firmware components that go beyond those described or illustrated without departing from the scope of the disclosure.

One or more procedures, processes and use cases from the 1-5 can be performed by a device whose illustrative configuration is shown in 5 is depicted, or more precisely by one or more engines, one or more program module (s), applications or the like, which can be executed on such a device. However, it should be understood that such operations can be implemented in conjunction with numerous other device configurations.

The in the illustrative processes and procedures in the 1-5 Operations described and illustrated may be performed or performed in any suitable order in various embodiments of the disclosure, as desired. In addition, at least some of the processes in certain exemplary embodiments can be carried out in parallel. Furthermore, in certain exemplary embodiments, fewer, more or different processes than those in FIGS 1-5 pictured are performed.

The 6-9 represent an additional embodiment similar to that in the 1-5 shown, being a third cloud-based server 180 added, which provides secure transaction processing capabilities for use in autonomous vehicles. According to some embodiments, an in 6 Illustrated exemplary architecture related to 1 described components, in addition to the third cloud-based server (s) 180, which provides secure transaction processing capabilities for use in autonomous vehicles. For the sake of brevity and clarity of description, it is understood that the architecture 600 each of the in 1 described and illustrated components includes, in addition to the third cloud-based server (s) 180. As far as possible, descriptions are from some aspects of the architecture 1 omitted to avoid redundancy. An additional functionality or interrelation of the first cloud-based server (s) 160 and the second cloud-based server (s) 170 related to the inclusion of the third cloud-based server (s) 180 is described below. Specific additions to the second cloud-based server (s) 170 (referred to as a mobility service server or mobility server) compared to the one in 1 illustrated second cloud-based server (s) 170 are discussed below.

It should be understood that while some of the embodiments disclosed herein provide for the use of a distributed architecture for secure transaction processing in automated vehicles, the systems and methods of the present disclosure can also be implemented in any vehicle configured to communicate over a network .

In general, architecture offers 600 a secure method of authenticating transactions (such as financial transactions in some Embodiments) to separate aspects of data collection, extracted biometric features and validation, personal information and financial information into mutually different processes. This balkanization minimizes a lot of useful information on any given system of architecture 600 stored in an effective manner so that each system keeps useful but incomplete records. In this way, a hacker would have to break into several different back-end systems and understand how they relate to one another in order to obtain meaningful information. For example, a credit card number without billing information (e.g. name, address, and so on) is useless. In another example, a subset of encrypted facial features without a user ID alone is relatively meaningless.

According to some embodiments, the architecture enables 600 out 6 the decentralization of biometric data, personalization data and financial / transaction data into incomplete data records that are stored on separate servers. A process for authenticating mobility services is carried out by first extracting biometric features in one cloud, carrying out a financial transaction in a separate cloud and storing personal information in another cloud so that the only common information is a customer identification number. That is, each of these clouds can retrieve, execute, and store data to perform one or more restricted services with a single customer identification number called an authentication identifier. This means that each / each of the different services / clouds does not need data from another cloud to perform a restricted service for a customer, but relies on the authentication identifier and a process of token exchange.

Architecture 600 out 6 also provides alternative authentication processes for customers who don't want to have their biometrics in the cloud but still want a secure, device-less financial transaction system. Architecture 600 out 6 also provides a process for integrating third-party applications to enable or facilitate other relevant third-party transactions (such as paying for fuel, buying films, and so on) in a secure and device-less manner. In some embodiments, the architecture 600 use a blockchain to unreliably exchange data and ensure that data can be securely transferred between a vehicle and one or more of the disclosed cloud services. In some embodiments, methods and systems that enable local or non-cloud-based biometric processing may include implementations in personal vehicles because such local biometric processing is less desirable in public environments such as carpooling or public transportation. If local processing is considered, another form of authentication could be used in some embodiments instead of using biometrics for authentication. For example, the user could provide a username and / or password. While embodiments in connection with local authentication can be preferred in personal vehicles, they can of course also be implemented in autonomous vehicles.

In general, the third is cloud-based server (s) 180 configured to process transactions for services. This third cloud-based server (s) 180 is / are also referred to as a financial cloud / server or transaction cloud / server. The transactions can be performed using data from any of the first cloud-based servers. 160 were obtained using an authentication token provided by the first cloud-based server (s) 160 was generated, processed.

In some embodiments, the third cloud-based server (s) comprise 180 (a) driver data server component (s) 182 , a payment information service 184 and an authentication identifier service 186 . The third cloud-based server (s) 180 can work with the first cloud-based server (s) 160 as well as with the second cloud-based server (s) 170 communicatively coupled over any suitable wireless network, as disclosed in more detail above. The third cloud-based server (s) 180 can also with the telematics control unit 150 of the autonomous vehicle 120 be communicatively coupled. A payment complete message 188 indicates a completed transaction (e.g., if a mobility service is authorized to pay).

In some embodiments, the biometric data provided by the first cloud-based server (s) 160 obtained and used, contain data that are publicly available in low resolution. For example, a driver's public profile photo obtained from a social network platform could be used. This low-resolution data is stored in advance for later use in authentication. While the Three-dimensional facial recognition in real time provides security, low-resolution images are likely to be readily available and public. It is understood that some customers would feel more comfortable using biometric data and will easily use a photo that is already publicly available. Such a low-resolution image is probably not enough to authenticate to the system, but would greatly reduce the incentive to attempt to hack into the biometric authentication server (compared to fingerprint recognition or properties of the iris).

The process of providing secure transactions within the architecture 600 out 6 is made in a process flow 7 illustrated. This in 7 illustrated method would be a first step 702 registration of a user by creating a personalized profile and generating a unique authentication identifier.

This process is initiated when a user has an account in a mobility service cloud (second cloud-based server) 170 ) created. This can also be done through an intelligent smartphone application (made possible by a smartphone), a dealer kiosk or a vehicle sales point for the vehicle. When an option to create an account is selected, the mobility cloud creates 170 a new personalized profile. This includes a standard set of personal information that includes, for example, the user's personal and / or demographic data. The process also creates an authentication identifier that is unique to the user. This identifier is then sent to the user's device that is used when creating the account. The identifier can be stored in a buffer, such as a random access memory (RAM) of the device used by the user, which is the autonomous vehicle 120 could include. The user's personal data can be stored in the second cloud-based server (s) 170 can be stored as discussed above.

Once a profile has been created, the procedure includes one step 704 for receiving and storing payment information from the user. This can be any supported form of financial transaction, such as a credit card number, check bank routing number, login information for a PayPal ™ account, and so on. When the user has provided their payment information, they are ready for transfer. The payment information is then sent to the third cloud-based server together with the authentication identifier 180 transferred for storage (see 6 ). In some embodiments, the payment information is in the payment information service 184 of the third cloud-based server (s) 180. The authentication ID is in the authentication ID service 186 saved.

In some embodiments, the method includes one step 706 in which the user registers biometric data for authentication. This is done using the first cloud-based server (s) 160 reached. These can be any biometric data, although in some embodiments a low quality version of the biometric data that is readily available is used to deter hackers. Again, this can include a photo that is easily accessible and currently publicly available. To complete this process, the user follows a series of prompts to interact with the biometric scanner, such as a camera, a fingerprint sensor, and so on. After the required characteristics have been extracted in a way that meets the data robustness requirements of the classifier, the biometric characteristics and the authentication identifier are sent to the biometric cloud (the first cloud-based server (s) 160 ) After completion, the procedure includes one step 708 to display a confirmation status for a user. The process also includes one step 710 to delete the authentication identifier from the RAM of the autonomous vehicle 120 (or other device that was used to register the user). The collective process of account creation and authentication identification generation, collection and storage of transaction data as well as collection and storage of biometric identifications using a smartphone of the user and instead of an HMI (Human Machine Interface) or the telematics control unit 150 of the autonomous vehicle 120 be performed. Additional aspects of biometric registration are related to 3rd disclosed and illustrated in more detail.

Once each of the cloud-based servers 160 , 170 and 180 has saved its respective data and the authentication identification data, the process proceeds to that of authentication. This process occurs in some embodiments after a mobility service is requested by the user. In general, a mobility service includes any service provided by a user through the autonomous vehicle 120 or another device is requested. It is also understood that mobility services can be facilitated by any vehicle or device that is designed according to the present Disclosure are configured, and not only with autonomous vehicles.

8th FIG. 12 is an exemplary flow diagram of an authentication process related to the present disclosure. In general, user authentication is initiated when at step 802 a request from a mobility service in the autonomous vehicle 120 Will be received. In privately owned vehicles, this can be done via a telematics control unit 150 (please refer 1 ) or another HMI. For an autonomous vehicle, authentication can be requested via any suitable service point, such as, for example, via an integrated infotainment tablet, or even via a mobile device (e.g. smartphone) that is connected to one of the autonomous vehicles 120 established wireless network is connected. If a desired service has been found, such as streaming a movie, the method includes a step 804 in which a user is asked to provide his biometric information for a biometric scanner of the autonomous vehicle 120 to provide. An exemplary input of biometric data is above with respect to the biometric input 130 out 1 described, the biometric raw data accepted by a user. The biometric scanner can of course be of any design. Private vehicles may include a fingerprint sensor integrated into a vehicle start button or a driver condition monitoring camera capable of face recognition. For autonomous vehicles, this may include a sensor (or a variety of sensors) integrated into a seat, armrest, or an available infotainment tablet or display.

Regardless of the means used for biometric input, the procedure can be one step 806 to process the scanned biometric data using the feature extraction component (s) 134 include. The feature extraction component (s) 134 can model feature inputs as needed. The standard features of the face would be the detection of edges to associate a face shape, the tracking of facial proportions such as the relative distance between the eyes and the length of the nose, blood vessel patterns detected by an infrared scan and changes in the three-dimensional depth detected by bifocal lenses or ultrasonic sensors , belong. This data could include a relative ratio of how far the cheeks protrude compared to the eye socket. The process includes one step 808 to encrypt and transmit the extracted features as an authentication challenge to the biometric server (the first cloud-based server (s) 160 ).

The authentication server 164 in the first cloud-based server (s) 160 would encrypt the received characteristics with a template archive (e.g. biometric templates 162 ) to compare. If no match is found, the first cloud-based server (s) can 160 with the autonomous vehicle 120 communicate to request a new biometric scan. The location of the service (such as the telematics control unit, the smartphone or the infotainment tablet or the entertainment system 121 ) provides feedback during this process, indicating when any biometric sensor is scanning, when the first cloud-based server (s) 160 carries out an authentication and indicates the status of the authentication. This process could be set to repeat itself as often as necessary to find the right account, or for a limited time / number of attempts to limit the possibility of theft. If no account is found, an option to register the user in a new account can also be provided. The procedure out 7 would then be run to register the user.

Once the first cloud-based server (s) 160 If there is a match, the method includes one step 810 to transmit a confirmation token to both the financial cloud (the third cloud-based server 180 ) as well as to the mobility cloud (the second cloud-based server 170 ). This confirmation token indicates that a specific authentication identifier and a corresponding user have been authenticated based on scanned biometric data. Thus, the receipt of this confirmation token enables the second cloud-based server (s) 170 and the third cloud-based server (s) 180 based at least in part on biometric user authentication by the first cloud-based server (s) 160 was carried out.

After receiving the authentication token from the biometric cloud (the first cloud-based server (s) 160 ) the procedure includes one step 812 to carry out a corresponding financial transaction through the financial cloud (the third cloud-based server 180 ). In detail, the financial cloud can use a desired financial system that a customer has provided for the execution of the sale. That is, the financial cloud can use pre-authorized or saved customer-provided financial options that are stored in the financial cloud. The transaction request can be repeated either for a limited number of attempts or for a limited duration. If it is successful, the procedure includes one step 814 to the Transfer a confirmation token to the mobility cloud (the second cloud-based server 170 ); otherwise the customer is provided with an abort error and a corresponding message.

In some embodiments, when a mobility service is requested, the mobility cloud (the second cloud-based server (s) is waiting 170 ) on confirmation tokens from both the biometric cloud and the financial cloud. This process can be configured so that the rejection by a cloud automatically leads to the transaction being canceled. For example, if the biometric data cannot be authenticated, the process is terminated before the financial cloud has to authorize a transaction.

In another embodiment, the transaction can be ended based on a time frame (ie, credit card processing takes too long). In any event that would result in a transaction being canceled, the customer would be notified of the location of the service, along with an explanation of the reasons why the service was refused. Once, on the other hand, both tokens have been received by each of the biometric cloud and the financial cloud, the process involves one step 816 , in which the user is provided access to the mobility service. Streaming movies, paying for fuel, and so on can all start in a device-independent manner. It goes without saying that separating financial transaction information can serve to support mobility service providers in complying with or excluding compliance requirements, such as the payment card industry (PCI) compliance. This is made possible if the mobility service provider uses the financial cloud (the third cloud-based server 180 ) does not own, operate or control. The financial cloud could be managed by a third party who is responsible for PCI compliance.

In one example, access to the mobility service is through an entertainment system 121 of the autonomous vehicle 120 provided. Here too, the provision platform for the mobility service can include other platforms such as a smartphone or a vending machine. In relation to 1 includes the second cloud-based server (s) 170 out 6 also a payment confirmation module 173 and a service delivery module 175 . The payment confirmation module 173 receives the payment complete message 188 from the third cloud-based server (s) 180. Upon receipt of the payment complete message 188, the service delivery module provides 175 then the requested service for the automated vehicle 120 and in some cases for the entertainment system 121 ready if the mobility service is video and / or audio media.

It is understood that the autonomous vehicle will never ever receive the authentication identifier. The authentication identifier is only between the biometric, financial and mobility clouds / servers 160 , 180 or. 170 exchanged. In this way, there should never be a time when the full data set of raw biometric data, authentication identifier, personal information or financial data, authentication identifier and personal information ever exists. Thus, mobility service providers and / or automated vehicle providers can reduce or eliminate their compliance requirements using the distributed architectures disclosed herein.

As previously mentioned, some customers may not want to share their biometric data, but still desire the security and efficiency that are provided by a decentralized system, such as that disclosed herein. To make this possible, the biometric server can also host alternative methods for authentication challenges. This can include a username along with one or more of: a password, a complex input pattern (such as on smartphone lock screens) and / or a unique combination of button presses on the vehicle - to name just a few.

Some embodiments also allow the location of biometric data in addition to being stored remotely in a biometric server. Such backup localization would generally be advantageous if, for example, a user has to retrain his biometric data. In one example, a customer may want to change the look of his face over time (such as when there is significant weight loss or other physical changes in appearance). Such changes may result in the classifier used by the first cloud-based server (s) 160 used, takes longer to recognize them. A traditional login password would solve these problems, providing a means for customers to log into their account and request that they be retrained. This process could be optimized by automatic retraining each time the biometric authentication fails but a successful reserve password is provided.

In some embodiments, the architectures disclosed herein may not only Provide mobility services for use within the autonomous vehicle, but can also be used for external or third-party mobility services, such as buying fuel or making purchases in third-party applications. In these scenarios, the processes for registration, authentication, and purchase verification mentioned above would be similar. However, the provision of services should also enable the reception, authorization and provision of a third-party server. A third-party provisioning service can do this 190 , as in 6 illustrates to be integrated into the architecture.

When using the external provision service 190 would require a request token to the third-party provisioning service in addition to a backend request to initiate the process 190 be transmitted. This third party delivery service 190 would be sent in an analogous manner to confirmation tokens from both the biometric and the financial server (server 160 and 180 ) who confirm that an authentication ID has been verified and a corresponding payment has been authorized. Upon receipt of these tokens, the third party service provider would 190 the mobility server (server 170 ) provide confirmation that the requested service is provided. This represents a closed loop within the request and authorization process, while the amount of information that the third party provisioning service is targeting 190 Access is minimized.

The processing of the transaction payment with the external provision service 190 can be performed in any suitable manner that would be known to one of ordinary skill in the art. For example, the third party service provider 190 after receiving the confirmation token, an invoice for the cost of the services provided to the customer or the financial server 180 transfer. This invoice may include the requestor's authentication identifier and data retention and future data analysis service, or may be completely anonymous, providing an invoice of the total cost, which is advantageous in that the customer stores their financial information only at a central marketplace the financial server 180 that is part of a secure and distributed architecture. In some embodiments, the financial server could 180 if required, the payment information can also be sent to the external provider 190 to transfer.

In addition, the architectures disclosed herein use a standard series of wireless communication methods in accordance with the security aspects of the present disclosure. This means that the clouds ( 160 , 170 , 180 ) meet the desired requirement to be only sets of relevant data; however, the means to actually transfer biometric and financial data when creating an account could theoretically be hacked. Therefore an alternative method would be to use a block chain to transmit this information. In these embodiments, customers would maintain a directory or wallet for which transactions are coordinated for reliable data exchange.

9 FIG. 10 is a flow diagram of another exemplary method of the present disclosure. The method generally involves processes for registering a user and then subsequently providing access to a mobility service for the user using a distributed architecture. In some embodiments, the method includes a process of registering a user by performing a step 902 to save a payment method or financial information for the user. This may include storing a credit card or financial information of a similar type. The process then includes one step 904 for generating an authentication identifier for the user and a step 906 to store low-quality or publicly available biometric data for the user. These steps can be done together when a record or profile is created for the user.

At any point in time, the user wants to access a mobility service such as a movie, music, or other service. The method thus includes one step 908 to receive a mobility service request. The process moves to a process of providing the mobility service by one step 910 to authenticate scanned biometric data. This may include comparing scanned biometric data to previously saved biometric data that is of low quality or is publicly available. In some cases, the comparison is made possible by using the authentication identifier to find the previously stored biometric data that are of low quality or are publicly available.

If authenticated, the process includes one step 912 to generate a biometric server authentication token after authenticating the user using the biometric data. This process involves one step 914 for receiving the biometric server authentication token and performing a transaction for the user using the Payment method or financial information to receive the mobility service. If the payment is authorized, the process goes to step 916 via, which involves generating a transaction server authentication token. The process then goes to step 918 , in which access to the mobility service is provided after receiving both the biometric server authentication token and the transaction server authentication token. As already mentioned, the authentication identifier can be used at every intermediate step. Thus, any part of the distributed process can use the authentication identifier to prevent each distributed part of the system from having to store and verify that the user or a transaction has been authenticated / authorized. In some embodiments, the transaction / finance server relies on the user's biometric authentication performed by the biometric server. In addition, the mobility server relies on the authentication of the biometric server and the transaction approval of the transaction / finance server to ultimately provide the mobility service, but anyone can use the authentication identifier.

Embodiments

In some cases, the following examples can be implemented together or separately by the systems and methods described in this document.

Example 1 may include a system comprising: a secure distributed network of servers, comprising: a biometric server configured to authenticate a user using biometric data and an authentication identifier for the user and to generate a biometric server authentication token, if the user is authenticated, the user being authenticated when a mobility service is requested from the user; a transaction server configured to perform a transaction upon receipt of the biometric server authentication token and authentication identifier, the transaction server further configured to generate a transaction server authentication token when the transaction is approved, the transaction allowing the user to access the Mobility service enabled; and a mobility service server configured to receive the biometric server authentication token, the transaction server authentication token and the authentication identifier and to provide access to the mobility service.

Example 2 may include the system of Example 1, wherein the biometric data is obtained from a user device that is wirelessly connected to an autonomous vehicle.

Example 3 can include the system according to Example 2 and / or another example of this document, the mobility service being requested by the user via an interface of the autonomous vehicle.

Example 4 may include the system of example 1 and / or another example of this document, the transaction server being further configured to store financial information for the user using the authentication identifier generated for the user.

Example 5 may include the system of example 1 and / or another example of this document, wherein the mobility service server is further configured to register the user by creating a personalized profile for the user and generating an authentication identifier for the user that is temporarily on a Device is stored, which is used by the user to generate the personalized profile.

Example 6 can include the system according to Example 5 and / or another example of this document, wherein, as soon as the user is registered by the mobility service, the temporarily stored authentication identifier for the user is deleted.

Example 7 may include the system of example 6 and / or another example of this document, and further includes scanning the user for the biometric data upon receiving a request for the mobility service, the scanned biometric data along with an authentication identifier generated for the user by the mobility service server transferred to the biometric server.

Example 8 may include the system of Example 7 and / or another example of this document, where authentication includes comparing the scanned biometric data to previously stored biometric data, the previously stored biometric data comprising a low quality photo or a publicly available photo of the user .

Example 9 may include the system of example 8 and / or another example of this document, wherein if no match is found using the scanned biometric data, the biometric server requests additional biometric scans of the user.

Example 10 may include the system of example 8 and / or another example of this document, where the previously stored biometric data can be updated by the user using a backup authentication method, to which using any password, a complex input pattern, a unique one Combination of key operations or combinations thereof is accessed.

Example 11 may include the system of example 8 and / or another example of this document, wherein the biometric data and financial information for the user are transmitted to the system using a block chain, the user maintaining a directory that is used to transmit the biometric data and which uses financial information.

Example 12 may include the system according to Example 1 and / or another example of this document, wherein the mobility service server provides access to the mobility service if the mobility service is associated with a foreign server.

Example 13 may include the system of Example 1 and / or another example of this document, where the biometric server, the transaction server and the mobility service server are physically separate servers that work together to deliver the mobility service, each using the user's authentication identifier.

Example 14 may include a method comprising: receiving, by a first computer, a mobility service request from a user that includes at least one processor coupled to at least one memory; and authenticating, for a user, biometric data scanned by a biometric server to a second computer that includes at least one processor coupled to at least one memory; Generating a biometric server authentication token by the second computer after authenticating the user; after receiving the biometric server authentication token by the first computer, performing a transaction for the user using a previously stored payment method for the user; A third computer generating a transaction server authentication token that includes at least one processor coupled to at least one memory when the transaction is approved; and upon receipt of both the biometric server authentication token and the transaction server authentication token by the first computer, providing access to the mobility service.

Example 15 may include a method that includes: registering a user by: storing a payment method or financial information for the user; Generating an authentication identifier for the user; and storing low quality or publicly available biometric data for the user; Receiving a mobility service request; and providing the mobility service by: authenticating scanned biometric data; Generating a biometric server authentication token after authentication; upon receiving the biometric server authentication token, performing a transaction for the user using the payment method or financial information to obtain the mobility service; Generating a transaction server authentication token when the transaction is approved; and after receiving both the biometric server authentication token and the transaction server authentication token, providing access to the mobility service.

Example 16 may include the method of Example 15 and further includes obtaining the scanned biometric data from a user device that is wirelessly connected to an autonomous vehicle.

Example 17 can include the method according to Example 16 and / or another example of this document, the mobility service being requested by the user via an interface of the autonomous vehicle.

Example 18 may include the method of example 17 and / or another example of this document, the authentication identifier being temporarily stored during the registration of the user.

Example 19 can include the method according to Example 18 and / or another example of this document, the temporarily stored authentication identifier for the user being deleted.

Example 20 may include the method of Example 15 and / or another example of this document, wherein the biometric data for the user, which is of low quality or is publicly available, can be updated by the user using a backup authentication method to which is accessed using any password, complex input pattern, unique combination of keystrokes, or combinations thereof.

While specific embodiments of the disclosure have been described, those of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functions and / or processing capabilities described with respect to a particular device or component can be performed by any other device or component. While various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, those of ordinary skill in the art will understand that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure.

Blocks of the block diagrams and flow diagrams support combinations of means for performing the specific functions, combinations of elements or steps for performing the specific functions, and program instruction means for performing the specific functions. In addition, it goes without saying that each block of the block diagrams and flow diagrams, as well as combinations of blocks in the block diagrams and flow diagrams, can be implemented by hardware-based special computer systems which carry out the specified functions, elements or steps, or combinations of special hardware and computer instructions.

A software component can be encoded in any of a variety of programming languages. An illustrative programming language can be a low-level programming language, such as an assembly language, that is associated with a specific hardware architecture and / or operating system platform. A software component that includes assembly language instructions may require conversion to executable machine code by an assembler prior to execution by the hardware architecture and / or platform.

A software component can be stored as a file or other data storage construct. Software components of a similar type or in a functional context can be stored together, for example in a specific directory, a specific folder or a specific library. Software components can be static (e.g. preset or fixed) or dynamic (e.g. created or modified at the time of execution).

Software components can call or be called by other software components by any of a wide variety of mechanisms. Called or calling software components can be other individually developed application software, operating system functions (e.g. device drivers, routines for data storage (e.g. file management), other common routines and services etc.) or software components from third-party providers (e.g. middleware, encryption or other security software, database management software, file transfer or other network communication software, mathematical or statistical software, image processing software and format conversion software).

Software components that are associated with a specific solution or system can be located on and run on a single platform or can be distributed across multiple platforms. The multiple platforms can be assigned to more than one hardware provider, more than one underlying chip technology or more than one operating system. Furthermore, software components that are assigned to a specific solution or a specific system can first be written in one or more programming languages, but can call software components that are written in other programming languages.

Computer-executable program instructions can be loaded onto a special purpose computer or other special machine, processor, or other programmable data processing device to create a special machine, so that executing the instructions on the computer, processor or other programmable data processing device causes one or more functions or one or more operations that are specified in the flowcharts are carried out. These computer program instructions may also be stored in a computer readable storage medium (CRSM) which, when executed, can instruct a computer or other programmable data processing device to function in a concrete manner such that the instructions stored in the computer readable storage medium generate an article of manufacture which includes instruction means which implement one or more functions or one or more processes which are specified in the flowcharts. The computer program instructions can also be loaded onto a computer or other programmable computing device to cause a series of operational elements or steps to be performed on the computer or other programmable device Setup is performed to create a computer-implemented process.

Although embodiments have been described in a language specific to structural features and / or methodological actions, it is understood that the disclosure is not necessarily limited to the specific features or actions described. Instead, the specific features and acts are disclosed as illustrative forms for implementing the embodiments. Language that expresses conditional relationships, such as “may”, “could”, “may” or “could”, is generally intended to convey that certain embodiments may include certain features, elements and / or steps, whereas other implementations do not unless otherwise specifically stated or something else arises from the context used. Thus, such language that expresses conditional relationships is generally not intended to imply that features, elements, and / or steps are required in any way for one or more embodiments, or that one or more embodiments necessarily include logic that is with or without input or prompting a user decides whether these features, elements and / or steps are contained or to be carried out in any specific embodiment.

According to the present invention, there is provided a system comprising: a secure distributed network of servers comprising: a biometric server configured to authenticate a user using biometric data and an authentication identifier for the user; and a biometric server authentication token generate when the user is authenticated, the user being authenticated when a mobility service is requested from the user; a transaction server configured to perform a transaction upon receipt of the biometric server authentication token and authentication identifier, the transaction server further configured to generate a transaction server authentication token when the transaction is approved, the transaction allowing the user to access the Mobility service enabled; and a mobility service server configured to receive the biometric server authentication token, the transaction server authentication token and the authentication identifier and to provide access to the mobility service.

In one embodiment, the biometric data is obtained from a user device that is wirelessly connected to an autonomous vehicle.

According to one embodiment, the mobility service is requested by the user via an interface of the autonomous vehicle.

In one embodiment, the transaction server is further configured to store financial information for the user using the authentication identifier generated for the user.

In one embodiment, the mobility service server is further configured to register the user by creating a personalized profile for the user and generating an authentication identifier for the user, which is temporarily stored on a device used by the user to obtain the personalized profile produce.

According to one embodiment, once the user is registered by the mobility service, the temporarily stored authentication identifier for the user is deleted.

According to one embodiment, the invention is further characterized by scanning the user for the biometric data when receiving a request for the mobility service, the scanned biometric data being transmitted to the biometric server together with an authentication identifier generated for the user by the mobility service server.

In one embodiment, authentication includes comparing the scanned biometric data to previously stored biometric data, the previously stored biometric data comprising a low quality photo or a publicly available photo of the user.

According to one embodiment, if no match is found using the scanned biometric data, the biometric server requests additional biometric scans of the user.

In one embodiment, the previously stored biometric data can be updated by the user using a backup authentication method that is accessed using any password, complex input pattern, unique combination of keystrokes, or combinations thereof.

According to one embodiment, the biometric data and financial information for the user are transmitted to the system using a block chain, the user being a Directory that is used to transfer the biometric and financial information.

In one embodiment, the mobility service server provides access to the mobility service when the mobility service is associated with a remote server.

In one embodiment, the biometrics server, the transaction server, and the mobility service server are physically separate servers that work together to provide the mobility service, each using the user's authentication identifier.

According to the present invention, a method includes: receiving a mobility service request from a user by a first computer that includes at least one processor coupled to at least one memory; and authenticating, for a user, biometric data scanned by a biometric server to a second computer that includes at least one processor coupled to at least one memory; Generating a biometric server authentication token by the second computer after authenticating the user; after receiving the biometric server authentication token by the first computer, performing a transaction for the user using a previously stored payment method for the user; A third computer generating a transaction server authentication token that includes at least one processor coupled to at least one memory when the transaction is approved; and upon receipt of both the biometric server authentication token and the transaction server authentication token by the first computer, providing access to the mobility service.

According to the present invention, a method includes: registering a user by: storing a payment method or financial information for the user; Generating an authentication identifier for the user; and storing low quality or publicly available biometric data for the user; Receiving a mobility service request; and providing the mobility service by: authenticating scanned biometric data; Generating a biometric server authentication token after authentication; upon receiving the biometric server authentication token, performing a transaction for the user using the payment method or financial information to obtain the mobility service; Generating a transaction server authentication token when the transaction is approved; and after receiving both the biometric server authentication token and the transaction server authentication token, providing access to the mobility service.

In one embodiment, the invention is further characterized by receiving the scanned biometric data from a user device that is wirelessly connected to an autonomous vehicle.

According to one embodiment, the mobility service is requested by the user via an interface of the autonomous vehicle.

According to one embodiment, the authentication identifier is temporarily stored during the registration of the user.

According to one embodiment, the temporarily stored authentication identifier for the user is deleted.

According to one embodiment, the user biometric data, which is of low quality or is publicly available, can be updated by the user using a backup authentication method to which any password, a complex input pattern, a unique combination of keystrokes or can be used Combinations of these are accessed.

QUOTES INCLUDE IN THE DESCRIPTION

This list of documents listed by the applicant has been generated automatically and is only included for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• US 16/041276 [0001]

Claims (15)

System comprising: a secure distributed network of servers comprising: a biometric server configured to authenticate a user using biometric data and an authentication identifier for the user and to generate a biometric server authentication token when the user is authenticated, the user being authenticated when a mobility service is requested from the user ; a transaction server configured to perform a transaction upon receipt of the biometric server authentication token and authentication identifier, the transaction server further configured to generate a transaction server authentication token when the transaction is approved, the transaction allowing the user to access the Mobility service enabled; and a mobility service server configured to receive the biometric server authentication token, the transaction server authentication token and the authentication identifier and to provide access to the mobility service. System according to Claim 1 wherein the biometric data is obtained from a user device that is wirelessly connected to an autonomous vehicle. System according to Claim 2 , wherein the mobility service is requested by the user via an interface of the autonomous vehicle. System according to Claim 1 wherein the transaction server is further configured to store financial information for the user using the authentication identifier generated for the user. System according to Claim 1 wherein the mobility service server is further configured to register the user by creating a personalized profile for the user and generating an authentication identifier for the user, which is temporarily stored on a device used by the user to create the personalized profile. System according to Claim 5 , wherein once the user is registered by the mobility service, the temporarily stored authentication identifier for the user is deleted. System according to Claim 6 , further comprising scanning the user for the biometric data upon receiving a request for the mobility service, the scanned biometric data being transmitted to the biometric server together with an authentication identifier generated for the user by the mobility service server. System according to Claim 7 wherein authenticating comprises comparing the scanned biometric data to previously stored biometric data, the previously stored biometric data comprising a low quality photo or a publicly available photo of the user. System according to Claim 8 , wherein if no match is found using the scanned biometric data, the biometric server requests additional biometric scans of the user. System according to Claim 8 wherein the previously stored biometric data can be updated by the user using a backup authentication method that is accessed using any password, a complex input pattern, a unique combination of keystrokes, or combinations thereof. System according to Claim 8 wherein the biometric data and financial information for the user are transmitted to the system using a block chain, the user maintaining a directory used to transmit the biometric data and the financial information. System according to Claim 1 , wherein the mobility service server provides access to the mobility service when the mobility service is associated with a remote server. System according to Claim 1 , wherein the biometrics server, the transaction server and the mobility service server are physically separate servers that work together to provide the mobility service, each using the user's authentication identifier. A method comprising: receiving a mobility service request from a user by a first computer that includes at least one processor coupled to at least one memory; and authenticating, for a user, biometric data scanned by a biometric server to a second computer that includes at least one processor coupled to at least one memory; Generating a biometric server authentication token by the second computer after authenticating the user; after receiving the biometric server authentication token by the first computer, performing a transaction for the user using a previously stored payment method for the user; A third computer generating a transaction server authentication token that includes at least one processor coupled to at least one memory when the transaction is approved; and upon receipt of both the biometric server authentication token and the transaction server authentication token by the first computer, providing access to the mobility service. Process comprising: Register a user by: Storing a payment process or financial information for the user; Generating an authentication identifier for the user; and Store biometric data that is of low quality or are publicly available to the user; Receiving a mobility service request; and Deliver the mobility service through: Authenticate scanned biometric data; Generating a biometric server authentication token after authentication; after receiving the biometric server authentication token, performing a transaction for the user using the payment method or financial information to obtain the mobility service, Generating a transaction server authentication token when the transaction is approved; and after receiving both the biometric server authentication token and the transaction server authentication token, providing access to the mobility service.

Images