Vehicle interaction authentication

Abstract

A method performed using a vehicle comprising a data processor and a memory element storing a vehicle interaction module and a transaction processing module. The method includes receiving, by the vehicle interaction module, a communication relating to operation of or access to the vehicle, after a user of the vehicle has performed an authentication process. The communication has data relating to an outcome of the authentication process. The method includes receiving, by the transaction processing module from a resource provider application, a transaction request, and obtaining, by the transaction processing module, from the vehicle interaction module, the data relating to the outcome of the authentication process. The method also includes providing, by the transaction processing module to the resource provider application, access data and the data relating to the outcome of the authentication process.

Description

VEHICLE INTERACTION AUTHENTICATIONCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is a PCT application, which claims priority to U.S. Provisional Application No. 63 / 580,695, filed on September 5, 2023, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] Most modem vehicles are equipped with digital car key functionality, allowing a user to unlock their vehicle using a mobile device after the user authenticates to the mobile device. The vehicle may request of the user to re- authenticate themselves for other reasons. For example, a user that wants to charge their vehicle at an EV (electric vehicle) charging station using application on the vehicle may need to re-authenticate themselves to the vehicle or the application before charging their vehicle. User convenience is a priority and therefore it is desired to avoid excessive and unnecessary authentication requests.

[0003] Embodiments of the disclosure address this problem and other problems individually and collectively.SUMMARY

[0004] One embodiment of the invention is related to a method performed using a vehicle comprising a data processor and a memory element storing a vehicle interaction module and a transaction processing module, the method comprising: receiving, by the vehicle interaction module in the vehicle, a communication relating to operation of or access to the vehicle, after a user of the vehicle has performed an authentication process, wherein the communication comprises data relating to an outcome of the authentication process; receiving, by the transaction processing module from a resource provider application, a transaction request; obtaining, by the transaction processing module, from the vehicle interaction module, the data relating to the outcome of the authentication process; and providing, by the transactionprocessing module to the resource provider application, access data and optionally the data relating to the outcome of the authentication process, wherein the resource provider application processes the transaction using the access data and the optional data relating to the outcome of the authentication process.

[0005] Another embodiment is related to a vehicle comprising a data processor and a memory element storing a vehicle interaction module and a transaction processing module, executable by the processor for implementing a method. The method comprises receiving, a communication relating to operation of or access to the vehicle, after a user of the vehicle has performed an authentication process, wherein the communication comprises data relating to an outcome of the authentication process; receiving, from a resource provider application, a transaction request providing, to the resource provider application, access data and optionally the data relating to the outcome of the authentication process, wherein the resource provider application processes a transaction using the access data and the optional data relating to the outcome of the authentication process.

[0006] These and other embodiments are described in further detail below.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 shows a block diagram of a system for processing in-vehicle transactions.

[0008] FIG. 2 shows a block diagram of another system and process flow illustrating an exemplary in-vehicle transaction processing method according to some embodiments of the invention.

[0009] FIG. 3 shows a block diagram of a vehicle according to some embodiments of the invention.

[0010] FIG. 4 shows a block diagram of a user device according to some embodiments of the invention.DETAILED DESCRIPTION

[0011] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0012] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0013] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a key fob, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. A user device may also be a credit, debit, or prepaid card.

[0014] An “application” may be computer code or other data stored on a computer readable medium that may be executable by a processor to complete a task.

[0015] 'Access data" may include any suitable data that can be used to access a resource or create data that can access a resource. In some embodiments, access data may be account information for a payment account, or an any other suitable identifier that can be used to access an individual vehicle. Account information may include a PAN, payment token, expiration date, card verification values (e.g., CVV, CW2), dynamic card verification values (dCVV, dCW2), an identifier of an issuer with which an account is held, etc. In other embodiments, access data could include data that can be used to access a locationor to access secure data. Such information may be ticket information for an event, data to access a building, transit ticket information, passwords, biometrics or other credentials to access secure data, etc.

[0016] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes and other login information, etc.

[0017] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.

[0018] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and / or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0019] “Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitutenumber that may be associated with the real credential. Further, tokenization can be applied to any other information to substitute the underlying information with a token. “Token exchange” or “de-tokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, de-tokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).

[0020] A “cryptogram” may include a piece of obscured text such as encrypted text. A cryptogram may be formed by encrypting input data with an encryption key such as a symmetric encryption key. In some embodiments, a cryptogram is reversible so that the inputs that are used to form the cryptogram can be obtained using the same symmetric key to perform a decryption process. In some embodiments, if input data is encrypted using a private key of a public / private key pair, the cryptogram may also be a digital signature. A digital signature may be verified with a public key of the public / private key pair. In some embodiments, a cryptogram may include a dCW (dynamic card verification value).

[0021] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc. A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.

[0022] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorizing entity may operate an authorizing entity computer. An “issuer” may refer to a business entity (e.g., a bank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellulartelephone, smart card, tablet, or laptop to the consumer, or in some embodiments, a portable device.

[0023] An “authorization request message” may be an electronic message that requests authorization for an interaction. In some embodiments, it is sent to a transaction processing computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with International Organization for Standardization (ISO) 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CW (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a user name, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction value, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0024] A “secure element” refers to a tamper-resistant platform (e.g., a secure microchip comprising a secure microcontroller and secure memory) capable of securely executing applications and storing data (e.g., cryptographic keys). A secure element may be embedded within a computing device itself or it may be embedded within a subscriber identity module (SIM). The secure element may be secure because data stored within the secure element cannot be directly accessed, as memory can be accessed, but instead can only be accessed via requests made to the microcontroller of the secure element, which may implement a set of rules and requirements for access. Secure element technology can provide the following features at the hardware level:• Detection of hacking and modification attempts;• Creation of a Root of Trust (RoT) platform for encryption systems;• Provision of secure memory for storing private encryption keys, bank card details, and other information;• Cryptographically secure generation of random numbers;• Generation of keys — for example, pairs of private and public keys for asymmetric encryption

[0025] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0026] FIG. 1 shows a block diagram of a system for processing in-vehicle transactions. FIG. 1 shows a user 10 operating a user device 100 and a vehicle 200. The vehicle 200 may be in communication with the user device 100 and a resource provider computer 108 via a communications medium 150. The system may further include transaction processing subsystem which can include a processing network computer 112 in a processing network such as a payment processing network, and an authorizing entity computer 114, which may be in communication with the resource provider computer 108 and transport computer 110. The resource provider computer 108 is in communication with the authorizing entity computer 114 via the transport computer 110 and the processing network computer 112.

[0027] Messages between at least the devices of the system in FIG. 1 can be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and / or the like. The communications network may include any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like. The communications network can use any suitable communications protocol to generate one or moresecure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.

[0028] The resource provider application 204 can be an application stored in a memory element of the vehicle 200. The resource provider application 204 is associated with a resource provider and enables the user 10 to communicate with the resource provider computer 108. The resource provider application 204 can allow a user to conduct a transaction with a resource provider and obtain a resource in exchange for payment. For example, in some embodiments, the resource provider application 204 can allow a user to purchase resources, which can be provided to the user of the vehicle 200 after completion and authorization of the transaction.

[0029] In embodiments of the invention, the user 10 may authenticate themselves to the user device 100 to unlock the vehicle 200 (e.g., with a vehicle key application on a mobile phone). The user 10 can also initiate transactions in the vehicle 200 from a resource provider application 204. For example, the user 10 can pay for a vehicle charging session from inside the vehicle 200. The user requests a charging session via resource provider application 204, and the resource provider application 204 requests a credential (e.g., PAN) to process the payment. The resource provider application 204 receives the credential (e.g., from user input or from a memory in the user device 100), and transmits it to the resource provider computer 108. In some methods, the user 10 may also be authenticated using a one-time password, a static password, biometric, etc.

[0030] The resource provider computer 108 can be configured to transmit an authorization request message comprising the credential to the authorizing entity computer 114 via the transport computer 110 and the processing network computer 112. The authorizing entity computer 114 can be configured to make an authorization decision on the authorization request message.

[0031] In some embodiments, the authorization request message comprises the credential (or a token) and a cryptogram that is generated by the vehicle 200. The processing network computer 112 receives the authorization request message from the resource provider computer 108 via the transport computer 110, andverifies the cryptogram. If the authorization request message comprises the token instead of the credential, the processing network computer replaces the token with the underlying credential, and forwards the authorization request message comprising the credential, and the cryptogram or an indication that the cryptogram has been verified, to the authorizing entity computer 114 for an authorization decision.

[0032] After the authorizing entity computer 114 makes the authorization decision, it returns an authorization response message back to the resource provider computer 108 via the processing network computer 112, the transport computer 110, and the resource provider computer 108. The user 10 may be granted access to the resource. If the authorization request message generated by the resource provider computer 108 included the token, then the authorization response message from the authorizing entity computer 114 may comprise the credential. The processing network computer 112 can re-tokenize the credential and may include the credential in the authorization response message that is sent back to the resource provider computer 108.

[0033] At a later time, a clearing and settlement process may be subsequently performed between the transport computer 110, the processing network computer 112, and the authorizing entity computer 114.

[0034] FIG. 2 shows a block diagram of a system along with a process flow for an in-vehicle transaction according to some embodiments. FIG. 2 shows a user device 100 in communication with a vehicle 200 via a communication channel (e.g., Bluetooth™, Wi-Fi™, etc.).

[0035] The user device 100 can include an authentication device such as a biometric reader, and a first vehicle key application 101 . Further details regarding the user device 100 are provided below, with respect to FIG. 4.

[0036] The vehicle 200 includes a resource provider application 204 (e.g., in- car app requiring payment and CVMs - card verification methods), a second vehicle key application 201 (e.g., a digital car key application), a transaction processing module 202 (e.g., a payment applet) and a vehicle interaction module 203 (e.g., a digital car key applet). Further details regarding the vehicle are described above with respect to FIG. 3. The vehicle interaction module 203 can be in the secure element205 and can transmit and receive data to and from the transaction processing module 202. For example, the vehicle interaction module 203 may store user profile data and data related to the outcome of authentication processes, which may be sensitive data. The transaction processing module 202 may store user credentials which may be sensitive data. To reduce the risk of unauthorized access (e.g., hacking) or tampering, the transaction processing module 202 and the vehicle interaction module 203 can exchange the sensitive data within the secure element 205.

[0037] The secure element 205 (or some other secure container) can protect sensitive data and operations. In some embodiments, the application in the user device 100 would perform user authentication (e.g. biometric verification), and communicate this information to the vehicle 200. The communications would be integrity-protected. The verification would take place inside the application in the secure element 205.

[0038] Embodiments can leverage vehicle owner authentication as a method of user verification for a transaction such as a payment transaction. The user verification can be a cardholder verification process. For example, the user can provide a biometric to a first vehicle key application 101 on the user device 100 (e.g., mobile phone), and the first vehicle key application 101 can compare the biometric to a stored biometric to determine if the received biometric is authentic. Authentication may also use secondary factors. For example, the primary verification of the user could use a biometric, but for that to be usable by a vehicle (e.g., car) key application such as the second vehicle key application 201 , there may need to be evidence that the vehicle (e.g., car) is close by (e.g. within range of a Bluetooth™ or Bluetooth™ LE connection and / or ultra-wideband connection). The outcome of the authentication process (e.g., in the form of an authentication indicator) is transmitted to a second vehicle key application 201 on the vehicle 200. If the authentication process outcome that is received by the second vehicle key application 201 and authenticated by the vehicle interaction module 203 indicates that the authentication of the user was successful, the vehicle 200 is then unlocked for the user and the vehicle interaction module 203 stores a status that the user has been successfully authenticated. This status can be communicated to or queried by any other applications within the vehicle 200 that requires verification. For example, when the second vehicle keyapplication 201 receives the data related to the outcome of the authentication, it can transmit to the vehicle interaction module 203 a communication relating to operation of or access to the vehicle 200. The communication can comprise the data relating to the outcome of the authentication process, and may cause the vehicle interaction module 203 to activate a user profile and / or unlock the vehicle 200 for the user. The user profile and authentication status may remain active until the user exits and locks the vehicle 200. The persistence of the status is a desirable aspect. The best use case for the user is that they unlock the vehicle (e.g., car) as they normally would, their status is set to “authenticated,” and that status persists until they lock the vehicle (e.g., car) (and “lock the car” may in itself be automatically triggered when the vehicle (e.g., car) detects that the user device (e.g., the user’s phone) is some meters away) - while the vehicle (e.g., car) is unlocked, any other application similar to the resource provider application 204 would be informed that the status = “verified”. The vehicle interaction module 203 could receive a second communication relating to the operation or the access of the vehicle, wherein the second communication locks the vehicle 200. The user status can expire when the vehicle is locked.

[0039] After completing the authentication process, the user may wish to initiate a transaction using the resource provider application 204 which queries the transaction processing module 202 with a transaction request. The resource provider application 204 may be, for example, an electric car charging application and the user may wish to purchase electricity to charge the vehicle 200. When the transaction processing module 202 receives a transaction request from the resource provider application 204, it retrieves the data related to the outcome of the authentication from the vehicle interaction module 203 and checks the user profile status. If the profile status is active, it indicates that the user has already been authenticated by the first vehicle key application 101. If the user has already been authenticated, the transaction processing module 202 can then transmit the credential to the resource provider application 204 without requiring the user to complete a separate authentication process for the transaction (e.g., a cardholder verification process). The transaction processing module 202 may further transmit to the resource provider application 204 the data related to the outcome of the authentication.

[0040] The process shown in FIG. 2 can be initiated by a user unlocking the vehicle 200 with the user device 100 and initiating an in-vehicle transaction.

[0041] In step S1 , a user authentication process is performed using the user device 100 to access the vehicle 200. The user authentication process can include a biometric verification process. For example, the user may provide their fingerprint to the first vehicle key application 101 via a biometric reader on the user device 100. The first vehicle key application 101 can compare the fingerprint to stored data in order to determine an outcome of the authentication. In other embodiments, the OS (operating system) of the user device 100 can perform the biometric verification and provide the result to the first vehicle key application 101 (e.g., if an application on a mobile phone needs consumer authentication by Touch ID, it asks the OS (e.g., iOS) to do the fingerprint capture, etc., and return a result).

[0042] In step S2, the first vehicle key application 101 can transmit to the second vehicle key application 201 a communication comprising data related to the outcome of a user authentication and key data (which are examples of data related to the operation of or access to the vehicle). This may be performed through a short range communication protocol such as Bluetooth™. The key data may be capable of unlocking the vehicle 200 and / or setting an active profile status for the user. The key data could include secret that is shared between the user device 100 and the vehicle 300, or it could include a digital signature produced by a private key in the user device 100, which is later verified by the vehicle interaction module 203 using a public key corresponding to the private key.

[0043] In step S3, after receiving the authentication data and key data from the first vehicle key application 101 , the second vehicle key application 201 passes the data to the vehicle interaction module 203. The vehicle interaction module 203 can associate the data indicating the verified user and the key data with a corresponding vehicle user profile. The profile status can be set to active and the vehicle 200 can be unlocked for the user to operate. Data indicating the profile status can be stored in the second vehicle key application 201 or the vehicle interaction module 203 in secure element 205 and an active status can be maintained until the user exits and locks the vehicle 200.

[0044] At some point after the user has unlocked the vehicle 200, in step S4, the user may initiate a request for a transaction with the resource provider application 204 (e.g., an in-car app requiring payment). The resource provider application 204 can be located in the memory element 210 of the vehicle 200, but not is not stored in the secure element 205. The memory element 210 may be a general memory area in the memory of the vehicle 200 that is less secure than the secure element 205. The memory element 210 and the secure element 205 may be part of the memory of the vehicle 200. For example, the user may stop at a charging station and initiate payment from within the vehicle 200 via resource provider application 204. The user may initiate payment by inputting an identifier for a charge terminal (e.g., by scanning a QR code on the charge terminal) and a selection that they wish to begin charging the vehicle 200. In other embodiments, the payment processing may be automatically initiated by the vehicle 200 immediately after the user has plugged in a charging cable. In embodiments of the invention, the transaction does not need to be associated with the operation of the vehicle 200. In another example, the resource provider application 204 may be associated with a quick service restaurant. The user may order a meal from the vehicle 200 via resource provider application 204.

[0045] In step S4, the resource provider application 204 may send a transaction request to the transaction processing module 202. The transaction request may query the transaction processing module 202 for a credential.

[0046] After receiving the transaction request from step S4, the transaction processing module 202 may require a form of transaction authentication (e.g., cardholder verification) for security. In step S5, rather than requesting authentication data directly from the user (e.g., via another biometric verification process), the transaction processing module 202 can query the vehicle interaction module 203 for the stored profile status data. The transaction processing module 202 can request the data relating to the outcome of the authentication process from the vehicle interaction module 203. For example, prior to sending the credential to the resource provider application 204, the transaction processing module 202 checks the user profile status to determine if the user profile is active.

[0047] In step S6, the vehicle interaction module 203 can transmit the data relating to the outcome of the authentication process to the transaction processing module 202. In some embodiments, the data relating to the outcome of the authentication process can be an indication that the user profile status is active.

[0048] In step S7, if the transaction processing module 202 receives an indication of an active profile status from the vehicle interaction module 203 (if the outcome of the authentication was successful), it confirms positive verification and sends a credential associated with the active user profile to the resource provider application 204. The transaction processing module 202 optionally sends the data relating to the outcome of the authentication process to the resource provider application 204. The resource provider application 204 can then process a payment transaction using the credential and optionally the data relating to the outcome of the authentication process. In some embodiments, the data relating to the outcome of the authentication process can be embedded in a transaction cryptogram that is generated by the transaction processing module 202. The transaction cryptogram can be formed by encrypting the outcome of the authentication process, and other information such as the credential. In other embodiments, the data relating to the outcome could be embedded in a chip data element such as “Issuer Application Data”, which is a part of the set of data that is protected by the transaction cryptogram (the cryptogram can be a MAC that protects a set of data for integrity).

[0049] In some embodiments, the resource provider application 204 may process the payment transaction by transmitting an authorization request message to an authorizing entity via a transport computer and processing network computer, as described with reference to FIG. 1. The authorizing entity can make an authorization decision. The authorization request message can comprise the credential and the data relating to the outcome of the authentication process. The data relating to the outcome of the authentication process may provide an extra layer of security and can help the authorizing entity make the authorization decision. For example, there may be less risk associated with transactions that are initiated in a vehicle with a positive user profile status, and the authorizing entity may be more likely to authorize the transaction.

[0050] Alternatively, in step S7, if the transaction processing module 202 does not receive an indication of an active profile status from the vehicle interaction module 203, it may request that the user authenticate themselves as the authentic user (e.g., authentic cardholder). For example, the user may be required to provide a biometric or provide a PIN or biometric into the vehicle 200 to verify that they are the legitimate user (e.g., legitimate cardholder) prior to continuing. In other embodiments, the vehicle 200 can trigger a user authentication on the user device 100, which is wirelessly connected to the vehicle 200.

[0051] In some embodiments, the vehicle interaction module 203 need not be within the secure element 205, although this is preferred for improved security. Also, in some embodiments, a user device 100 is not required. The functions of the user device 100 or the user device 100 itself can be in the vehicle 200. For example, the vehicle may be equipped with a biometric reader, and the second vehicle key application 201 may determine the outcome of the authentication process.

[0052] Some embodiments may leverage a secure element differently than shown in FIG. 1. For example, the user device may leverage a secure element. In some embodiments, the transaction processing module may not leverage secure element. The vehicle interaction module may operate entirely in secure element or may not involve secure element at all, and in those instances steps S2 and S3 may be combined into one step.

[0053] FIG. 3 illustrates a block diagram of a vehicle 300, according to some embodiments. Vehicle 300 can be, for example, an electric car. Although vehicle 300 may be described as an automobile, it should be understood that in some embodiments, the techniques described herein can also be applied to other types of vehicles such as motorcycles, boats, aircrafts, or other types of powered machines that are used to transport a user from one location to another.

[0054] Vehicle 300 may include various electronic control units (ECUs) to operate and control the electrical system or other subsystems of vehicle 300, and may include sensors 335 that the ECUs can monitor. Each ECU may include a microcontroller and one or more memories (e.g., any combination of SRAM, EEPROM, Flash memories, etc.) to store one or more executable programs for the ECU. Examples of ECUs may include engine / motor control unit 310, transmissioncontrol unit 320, etc. In some embodiments, vehicle 300 may include additional ECll(s) not specifically shown, omit one or more ECUs, and / or integrate any of the functionalities of different ECUs into a single ECU.

[0055] Vehicle 300 can also include a battery system 330 comprising one or more batteries and a charge interface 333 for charging the one or more batteries. The battery system 330 and the charge interface 333 can be in communication with and coupled to the in-vehicle computing system 350 and its processor 352.

[0056] Engine I motor control unit 310 may control the actuators, valves, motor, and / or other components of the engine of vehicle 300, or an electric motor of the vehicle 300. Transmission control unit 320 may control the gear shifting and the transmission modes (e.g., park, drive, neutral, reverse) of vehicle 300. Battery system 330 may include electronics that can control the electrical voltage and current supplied by its one or more batteries to the various components of vehicle 300. Sensors 335 may include vehicle speed sensors (e.g., wheel sensors) to detect the speed of vehicle 300, temperature sensors to detect the operating temperature of the vehicle’s various components, air sensors to detect oxygen level in the engine, sensors to detect the amount of energy currently (e.g., electricity, gas, etc.) present with the vehicle or the available capacity of any energy storage devices such batteries, cameras to observe the surroundings of vehicle 300, etc. The various ECUs, devices, and sensors may communicate with one another via a vehicle communication bus. Examples of vehicle communication bus may include a controller area network (CAN) bus, a local interconnect network (LIN) bus, a vehicle area network (VAN) bus, or other suitable signal buses for vehicle communication.

[0057] Vehicle 300 may also include various radio frequency (RF) transceivers to allow vehicle 300 to receive and transmit RF signals with other devices. For example, vehicle 300 may include a positioning satellite receiver 370 such as a GPS receiver to receive satellite signals that can be demodulated and decoded to determine the location of vehicle 300. The positioning satellite receiver 370 can be used by a positioning or navigation subsystem of vehicle 300 to perform routing and mapping functions.

[0058] Vehicle 300 may also include a wireless communication subsystem 390 to enable network connectivity for vehicle 300. Wireless communicationsubsystem 390 may include one or more wireless transceivers that use WiFi, WiMax, or other types of wireless network communication protocols to connect vehicle 300 to an external network (e.g., the Internet) such that vehicle 300 can communicate with remote servers. Wireless communication subsystem 390 may also include one or more short or near range wireless transceivers such as RFID, Bluetooth or Bluetooth Low Energy, NFC, beacon, infrared transmitters and / or receivers that can be used to communicate with an access device in proximity to vehicle 300.

[0059] Vehicle 300 may also include an in-vehicle computing system 350 with which a user of vehicle 300 can interact. In-vehicle computing system 350 can be an infosystem, infotainment system, or other instrumentation system. In-vehicle computing system 350 can be mounted in the center console, dashboard, rear console, or other locations in vehicle 300 that is convenient for a user to access the in-vehicle computing system 350. In some embodiments, in-vehicle computing system 350 can be coupled to vehicle communication bus to receive vehicle status information from the ECUs and sensors 335.

[0060] In-vehicle computing system 350 may include a processor 352, a memory 360, and user interface 354. User interface 354 may include an input interface such as any number of buttons, knobs, microphone and / or a touchscreen that can receive user input, and an output interface such as a display (may be part of a touchscreen) and / or speakers. The display of user interface 354 can be integrated with the housing of in-vehicle computing system 350, or can be a separate component coupled to in-vehicle computing system 350 but mounted at a different location than in-vehicle computing system 350. For example, the display of user interface 354 can be mounted on the surface of the center console, on the dashboard, on the surface of the rear console, behind the headrest, on the interior ceiling, on the visor, or other suitable location in vehicle, and may display various types of information including information such as vehicle status information (e.g., speed, fuel economy, engine temperature, etc.), environmental information (e.g., inside / outside temperature, weather, etc.), navigation information (e.g., maps, routes, places of interests, etc.), entertainment such as videos or titles of audio selections or radio stations, energy level information (e.g., amount of charge present and needed to fill to capacity, amount of gas present and needed to fill to capacity), transaction information, energy terminal information, etc.

[0061] Memory 360 may include any combination of SRAM, DRAM, EEPROM, Flash, and / or other types of memories, etc. The memory 360 may include the secure element 205 and the memory element 210 in FIG. 2. Memory 360 may store a number of applications such as second vehicle key application 362, transaction processing module 364, a resource provider application 366, and vehicle interaction module 367. In some embodiments, a number of the applications may be within a secure element. For example, as described in the example of FIG. 2, the cryptographic keys 368, vehicle interaction module 367 and transaction processing module 364 may exist within a secure element.

[0062] Second vehicle key application 362 can comprise code, executable by processor 352 for providing vehicle key functionality and enabling a user to access the vehicle. The second vehicle key application 362 may comprise executable code for sending and receiving authentication data and key data. For example, as described in the method of FIG. 2, the second vehicle key application 362 may comprise executable code for receiving authentication data and key data from a first vehicle application on a user device, and transmitting the data to the vehicle interaction module 367.

[0063] The vehicle interaction module 367 can comprise code, executable by the processor 352 for receiving communications related to the operation of or access to a vehicle, unlocking the vehicle 300, and configuring user profiles. For example, the vehicle interaction module 367 may comprise executable code for upon receiving data related to a successful authentication, unlocking the vehicle 300 and setting a user profile status to active. The vehicle interaction module 367 may manage and store various user profiles and user data.

[0064] The resource provider application 366 may comprise code, executable by the processor 352 for conducting transactions with a resource provider, and granting access to resources. For example, the resource provider application 366 may comprise code, executable by the processor 352 for enabling a user to purchase a charging session and begin charging the vehicle 300.

[0065] Transaction processing module 364 enables in-vehicle computing system 350 to conduct transactions for the vehicle 300. In some scenarios, transaction processing module 364 may allow a user of vehicle 300 to execute atransaction (e.g., a payment transaction) with a resource provider computer without requiring the user to exit the vehicle 300, and without requiring the user to use another device such as the user’s payment card or mobile device. Transaction processing module 364 may store account credentials or tokens, or reference identifiers thereof for various accounts. The transaction processing module 364 may comprise code, executable by the processor 352, for receiving transaction requests (e.g., from a resource provider application), and transmitting credentials. For example, the transaction processing module 364 can comprise code for retrieving from the vehicle interaction module profile data (e.g., data relating to the outcome of the authentication process), and transmitting a credential associated with the profile data to the resource provider application 366. The memory 360 can also comprise cryptographic keys 368 can be used to encrypt data, sign data, verify data, etc.

[0066] The memory 360 can comprise a computer readable medium. The computer readable medium may comprise code, executable by the processor 352 to perform operations comprising: receiving, a communication relating to operation of or access to the vehicle, after a user of the vehicle has performed an authentication process, wherein the communication comprises data relating to an outcome of the authentication process; receiving, from a resource provider application, a transaction request; providing, to the resource provider application, a transaction credential and optionally the data relating to the outcome of the authentication process, wherein the resource provider application processes the transaction using the transaction credential and the optional data relating to the outcome of the authentication process.

[0067] FIG. 4 shows a block diagram of a user device 400 in according to an embodiment. The user device 400 may include device hardware 404 coupled to a system memory 402.

[0068] Device hardware 404 may include a processor 406, a short range antenna 414, a long range antenna 416, input elements 410, a user interface 408, and output elements 412 (which may be part of the user interface 408). Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices.

[0069] The long range antenna 416 may include one or more RF transceivers and / or connectors that can be used by user device 400 to communicate with other devices and / or to connect with external networks. The user interface 408 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of user device 400. The short range antenna 414 may be configured to communicate with external entities through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 416 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0070] The system memory 402 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media.

[0071] The system memory 402 may also store a communication module 402A, a first vehicle key application 402B, an authentication module 402C, and an operating system 402E. The authentication module 402C may comprise code, executable by the processor 406, to authenticate a user. This can be performed using user secrets (e.g., passwords) or user biometrics.

[0072] The communication module 402A may comprise code or software, executable by the processor 406, for communicating with other devices. The communication module 402A may be configured or programmed to perform some or all of the functionality associated with receiving, sending, and generating electronic messages for transmission through the user device 400. When an electronic message is received by the user device 400, it may be passed to the communication module 402A. The communication module 402A, in conjunction with the processor 406, may identify and parse the relevant data based on a particular messaging protocol used. The communication module 402A, in conjunction with the processor 406, may transmit any received information to an appropriate module within the user device 400. The communication module 402A, in conjunction with the processor 406, may receive information from one or more of the modules in the user device 400 and generate an electronic message in an appropriate data format inconformance with a transmission protocol so that the message may be sent to one or more entities within system illustrated in FIG. 1 .

[0073] The first vehicle key application 402B may be a digital car key application. The first vehicle key application 402B can comprise code or software, executable by the processor 406, for enabling a user to unlock a vehicle from a user device. For example, the first vehicle key application 402B can comprise code for transmitting authentication data and key data which unlocks a vehicle.

[0074] Embodiments of the disclosure have a number of technical advantages. When user wants to conduct a transaction using the vehicle after the user has already entered the vehicle, in embodiments of the invention, an additional user authentication interaction is not required for cardholder verification while there is an active profile status. Leveraging vehicle profile status as a method of user authentication advantageously removes the requirement to re-authenticate the user.

[0075] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0076] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g.,a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0077] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0078] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0079] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:1 . A method performed using a vehicle comprising a data processor and a memory element storing a vehicle interaction module and a transaction processing module, the method comprising: receiving, by the vehicle interaction module, a communication relating to operation of or access to the vehicle, after a user of the vehicle has performed an authentication process, wherein the communication comprises data relating to an outcome of the authentication process; receiving, by the transaction processing module from a resource provider application, a transaction request; obtaining, by the transaction processing module, from the vehicle interaction module, the data relating to the outcome of the authentication process; and providing, by the transaction processing module to the resource provider application, access data, and optional data relating to the outcome of the authentication process, wherein the resource provider application processes a transaction using the access data and the optional data relating to the outcome of the authentication process.

2. The method of claim 1 , wherein the vehicle interaction module and the transaction processing module are in a secure element in the memory element.

3. The method of claim 2, wherein the vehicle further comprises a vehicle key application in the memory element, but not in the secure element, and wherein the communication relating to operation of or access to the vehicle comes from a user device operated by the user, the user device being a mobile phone.

4. The method of claim 1 , wherein the outcome is a positive authentication, and the communication relating to operation of or access to the vehicle unlocks the vehicle.

5. The method of claim 4, wherein the communication relating to the operation of or access to the vehicle is a first communication, the method further comprising:receiving, by the vehicle interaction module, a second communication relating to operation of or access to the vehicle, wherein the second communication locks the vehicle, and wherein the data related to the outcome of the authentication process expires when the vehicle is locked.

6. The method of claim 1 , wherein the memory element further stores the resource provider application.

7. The method of claim 1 , wherein the access data comprises a credential.

8. The method of claim 1 , wherein the authentication process is a biometric verification.

9. The method of claim 1 , wherein the vehicle is an electric car.

10. The method of claim 1 , further comprising: after receiving the communication relating to operation of or access to the vehicle, determining, by the vehicle interaction module, a user profile based on the data relating to the outcome of the authentication process, wherein the user profile is associated with the access data.11 . The method of claim 1 , wherein the authentication process is performed on a mobile phone.

12. The method of claim 1 , wherein the authentication process is performed on the vehicle.

13. The method of claim 1 , wherein the resource provider application processes the transaction by transmitting the access data and the data related to the outcome of the authentication process to an authorizing entity computer for an authorization decision.

14. The method of claim 13, wherein the authorizing entity computer receives the access data and the data related to the outcome of the authentication process in an authorization request message.

15. A vehicle comprising: a processor; anda memory element storing a vehicle interaction module and a transaction processing module, executable by the processor for implementing a method comprising: receiving, a communication relating to operation of or access to the vehicle, after a user of the vehicle has performed an authentication process, wherein the communication comprises data relating to an outcome of the authentication process; receiving, from a resource provider application, a transaction request; and providing, to the resource provider application, access data and optional data relating to the outcome of the authentication process, wherein the resource provider application processes a transaction using the access data and the optional data relating to the outcome of the authentication process.

16. The vehicle of claim 11 , wherein the vehicle interaction module and the transaction processing module are in a secure element in the vehicle.

17. The vehicle of claim 12, wherein the vehicle further comprises a vehicle key application and wherein in the method, the communication relating to operation of or access to the vehicle comes from a user device operated by the user, the user device being a mobile phone.

18. The vehicle of claim 11 , wherein the authentication process is a biometric verification.

19. The vehicle of claim 11 , wherein the vehicle is an electric car.

20. The vehicle of claim 11 , the method further comprises: after receiving the communication relating to operation of or access to the vehicle, determining a user profile based on the data relating to the outcome of the authentication process, wherein the user profile comprises the access data.

Images